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W hen I was starting out 
in gaming, I bought 
magazines and books 
that contained video 
game programs and I 
had to type in the code 
if I wanted to experience them. 

Some were short and sweet; some 
were flight simulators and would take days 
to type in. But they served two purposes: 
they helped me to get better at typing and 
they allowed me to study the code and learn 
from the masters. I’d see their tricks and I’d 
see how their games functioned from the 
inside out. 

Soon I was writing my own magazine 
articles and books, and later ended up 
making full games. Thankfully, the publishers 
wanted to put them on game retail shelves. 

I’ve now been in the industry 
professionally for well over 30 years. I have had number- 
one hits and sold more than $ 1 billion of video games. 

I get asked ‘What’s the secret to making your game 
design a hit?’, but I only explain the ‘simple’ version of 
the answer: all addictive games need to incorporate skill, 
risk, and strategy at every moment. If you’re missing one 
of these, it’s going to get boring fast! Tetris ? Yep. Call of 
Duty? Yep. Angry Birds ? Yep. 

But, just for you... I’m going to give the full answer 
to the question. So here we have the real secret to making 
your game design a hit. 

There has to be blame. The player must blame 
themselves for any loss. If they blame the game balance or 
things outside their control, you lose. 

There has to be a retry rate. The player must be 
able to try again — in seconds - if they fail. Tetris would 
have failed if we had to watch a GG movie before we could 
try again. 



David Perry 

is one of the 
gaming industry's 
most successful 
developers. He 
started his career 
reading books 
like these and 
even wrote some 
of them himsef. 
Since then he has 
produced many 
popular games such 
as Aladdin and 
Earthworm Jim. 
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There has to be progress. Players must see progress 
after everything they do. We used to have scores, and that’s 
also why World of Warcraft levels up constantly. 

And there has to be feedback. If you do something 
impressive or amazing, the game should respond 
accordingly. Like Bejeweled would get crazy if long chains 
fall into place. Or when pinball machines would enter 
super multi-ball mode with all lights flashing. Think of the 
game as having its own emotional state. 

Now here’s the X-factor. These are multipliers to 
make your game even more addictive: 

Revenge. Let gamers fight back someone or 
something that’s been really frustrating them. ‘Payback 
time!’ Yes you can even remind them: ‘This guy over here, 
killed you last time!’ 

Social / multiplayer / viewers. Other people, even 
if they are only spectating, definitely add to the experience. 
So, embrace other players and community as much 
as possible. 

Time accelerators. 

Surprise the gamer 
by letting them make 
progress faster than they 
expected. This is why you 
see ‘experience boosts’ 
in massively multiplayer 
games: they are incredibly 
popular as they save time. 

My final tip? 

Humour. It’s the 
most rare and valuable 
thing in the video game 
industry. People never forget the games they laugh at. Even 
a slight bit of humour helps: for example, there were lots of 
boring catapult games before Angry Birds became a big hit. 

If you follow these ideas, you’ll have a fantastic 
head-start on other people that want to make games. 

I can’t wait to see what you make! 


People never 
forget the games 
they laugh at. 
Even a slight bit 
of humour helps 
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Chapter 1 

Tennis 


In the earliest days of gaming, 
all it took was a couple of Lines 
and a dot, and gamers would be 
queuing up to play 



T his simple game takes ping-pong as 
its inspiration and boils it down to the 
bare minimum. In the early 1970s, 
developers were forced to work with 
the most basic of technology, but even 
primitive graphics and sound couldn’t 
detract from Pong ’s addictive gameplay. In many ways, 
games like Pong are the ultimate in pick-up-and-play. The 
basic principle is easy to grasp for a player and it captures 
the essence of the sport perfectly To play, gamers control 
one of two paddles on either side of the screen to knock a 
ball back and forth until one of them misses. This requires 
concentration and skill while opening up the possibilities 
for two-player gameplay. Pong, which kick-started this kind 
of competitive gaming, was very successful for developer 
and publisher Atari, which shipped thousands of arcade 
cabinets across the world. 


Inspiration 

Pong was created by Allan Alcorn as a training exercise 
assigned to him by Nolan Bushnell, the co-founder of 
Atari. Video gaming was in its infancy and various people 
were playing around with ideas, experimenting with simple 
gameplay mechanics that would cause the first wave of 
gamers to become hooked. Since the games were being 
played on large arcade cabinets that required players 
to pump in coins to continue, the rules had to be simple 
enough to understand at a glance and addictive enough 
to encourage further plays. Nolan’s Atari was hugely 
successful and he eventually sold the company to Warner 
Communications for $28 million. 
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Pong 

Released 1972 

Platforms Arcade 

Dedicated consoles 


Atari 2600 
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The success of Pong led to the creation of Pong home consoles (and numerous unofficial 
clones) that could be connected to a television. Versions have also appeared on many 
home computers. 


Other Notables 


Sanrio World Smash Ball! / Gnop! / Windjammers 


Ask anyone to describe a game of table tennis and they’ll invariably tell you the same 
thing: the sport involves a table split into quarters, a net dividing the two halves, a 
couple of paddles, and a nice round ping-pong ball to bat back and forth between 
two players. Take a look at the 1972 video game Pong , however, and you’ll notice some 
differences. The table, for instance, is simply split in half and it’s viewed side-on, the 
paddles look like simple lines, and the ball is square. Yet no one - not even now - 
would have much trouble equating the two. 

Back in the early 1970s, this was literally as good as it got. The smattering of 
low-powered arcade machines of the time were incapable of realistic-looking graphics, 
so developers had to be creative, hoping imaginative gamers would fill the gaps and 
buy into whatever they were trying to achieve. It helped enormously that there was a 
huge appetite for the new, emerging video game industry at that time. Nolan Bushnell 
was certainly hungry for more — and had he 
turned his nose up at Spacewar /, a space combat 
game created by Steve Russell in 1962, then Pong 
would never even have come about. 

“The most important game I played was 
Spacewar! on a PDP-1 when I was in college,” he 
says, of the two-player space shooter that was 
popular among computer scientists and required 
a $120,000 machine to run. Although the visuals 
were nothing to write home about, the game was 
one of the first graphical video games ever made. 

It pitted two spaceships against each other and 
its popularity spread, in part, because the makers 
decided the code could be distributed freely to 

anyone who wanted it. “It was a great game, fun, challenging, but only playable on 
a very expensive computer late at night and the wee hours of the morning,” Nolan 
says. “In my opinion, it was a very important step.” 

Nolan was so taken by Spacewar! that he made a version of the game with a 
colleague, Ted Dabney. Released in 1971, Computer Space allowed gamers to control 
a rocket in a battle against flying saucers, with the aim being to get more hits than 
the enemy in a set period of time. To make it attractive to players, it was placed in a 
series of colourful, space-age, moulded arcade cabinets. Nolan and Ted sold 1500 of 
them; even though they made just $500 from the venture, it was 
enough to spur them into continuing. They came up with the I An original 1972 

idea for Pong and created a company called Atari. flyer to promote 

^ p i i ^ th© Launch 

(Jne ol their best moves was employing engineer of the Pong 

A1 Alcorn, who had worked with Nolan at the American arcade game 


The arcade 
machines of the 
time were incapable 
of realistic- 
looking graphics 
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electronics company Ampex. A1 was asked to create a table tennis game based on 
a similar title that had been released on the Magnavox Odyssey console, on the 
pretence that the game would be released by General Electric. In truth, Nolan simply 
wanted to work out ATs potential, but he was blown away by what his employee came 
up with. Addictive and instantly recognisable, Atari realised Pong could be a major 
hit. The game’s familiarity with players meant it could be picked up and played by 
just about anyone. 

Even so, Nolan had a hard time convincing others. Manufacturers turned the 
company down, so he visited the manager of a bar called Andy Gapp’s in Sunnyvale, 
California and asked them to take Pong for a week. The manager soon had to call 
Nolan to tell him the machine had broken: it had become stuffed full of quarters from 
gamers who loved the game. By 1973, production of the cabinet was in overdrive and 
8000 were sold. It led to the creation of a Pong home console which sold more than 
150,000 machines. People queued to get their hands on one and Atari was on its way 
to become a legendary games company. 

For Nolan, it was justification for his perseverance and belief. Suddenly, the 
man who had become interested in electronics at school, where he would spend time 
creating devices and connecting bulbs and batteries, was being talked of as a key 
player in the fledgling video game industry. But what did Nolan, Ted, Al, and the rest 
of the Atari team do to make the game so special? “We made it a good, solid, fun 
game to play,” says Nolan. “And we made it simple, easy, and quickly understood. 
Keeping things simple is more difficult to do than building something complex. You 
can’t dress up bad gameplay with good graphics.” 

Making Pong 

On the face of it, Pong didn’t look like much. Each side had a paddle that could be 
moved directly up and down using the controller, and the ball would be hit from one 
side to the other. The score was kept at the top of the screen and the idea was to force 
the opposing player to miss. It meant the game program needed to determine how 
the ball was hit and where the ball would go from that point. And that’s the crux of 
Pong's success: the game encouraged people to keep playing and learning in the hope 
of attaining the skills to become a master. 

When creating Pong, then, the designers had a few things in mind. One of the 
most important parts of the game was the movement of the paddles. This involved a 
simple, vertical rectangle that went up and down. One of the benefits Atari had when 
it created Pong was that it controlled not just the software but the hardware too. By 


The objectives 

Short term: Make sure you get the ball motion working perfectly so that the movement is fluid and it 
looks like it would in real life when hitting the paddles. 

Medium term: Work on the paddle angles. By ensuring the ball reacts in a realistic manner when it 
hits various parts of a moving paddle, skill is introduced. 

Long term: Nolan says you need to have a proper escalation of difficulty.Think about ways in which 
you can keep the best players wanting more. 
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building the cabinet, it was able to determine how those paddles should be moved. 
“The most important thing if you want to get the gameplay right is to use a knob to 
move the paddle,” advises Nolan. “No one has done a good Pong using touchscreens 
or a joystick.” 

Look at a Pong cabinet close up — there are plenty of YouTube videos 
which show the game in action on the original machine — and you will see what 

Nolan means. You’ll notice that players turned 
a knob anticlockwise to move the paddle down, 
and clockwise to move it up. Far from being 
confusing, it felt intuitive. 

Movement of the ball 

With the paddles moving, Atari’s developers 
were able to look at the movement of the ball. 
At its most basic, if the ball continued to make 
contact with the paddles, it would constantly 
move back and forth. If it did not make contact, 
then it would continue moving in the direction 
it had embarked upon and leave the screen. At 
this stage, a new ball was introduced in the centre of the screen and the advantage 
was given to the player who had just chalked up a point. If you watch footage of the 
original Pong , you will see that the new ball was aimed at the player who had just let 
the ball go past. There was a chance he or she would miss again. 

To avoid defeat, players had to be quite nifty on the controls and stay alert. 
Watching the ball go back and forth at great speed could be quite mesmerising as it 
left a blurred trail across the cathode ray tube display. There was no need to waste 
computing power by animating the ball because the main attention was focused on 
what would happen when it collided with the paddle. It had to behave as you’d expect. 
“The game did not exist without collisions of the ball to the paddle,” says Nolan. 

A1 realised that the ball needed to behave differently depending on where it 
hit the paddle. When playing a real game of tennis, if the ball hits the centre of the 
racket, it will behave differently from a ball that hits the edge. Certainly, the ball is 
not going to be travelling in a simple, straight path back and forth as you hit it; it is 
always likely to go off at an angle. This, though, is the trickiest part of making Pong. 


One of the most 
important parts 
of the game was 
the movement of 
the paddles 


Learn from the master 

Nolan BushneLL tells us what made Pong great. 

Simplicity is key: Nolan says Pong-like games must be simple to learn. Players should be able to pick 
up the fundamentals with hardly any instruction. 

Introduce complexity: The game should be designed so that it is difficult to master.This way, players 
will want to try to beat the game and have an incentive to do so. 

Bushnell’s Law: Both of these mechanics are encapsulated in what has come to be known as 
Bushnell’s Law. It says games “should reward the first quarter and the hundredth”. 
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“The ball should bounce up from an upper collision 
with more obtuse angles as the edge of the paddle is 
approached,” Nolan says. “This balances the risk of missing 
with the fact that an obtuse angle is harder to return.” This 
is what Pong is all about: making sure you hit the ball with the 
paddle, but in a manner that makes it difficult for the opposing 

player to return it. “A 
player wants the ball to 
be just out of reach for 
the opponent or be hard 
for him or her to predict.” 


The ball should 
bounce with more 
obtuse angles as the 
edge of the paddle 
is approached 


2 Various novelty 
Pong cabinets 
were released, 
including Barrel- 
Pong (pictured) 
and Snoopy Pong 

3 The original 
version of the 
Pong arcade 
cabinet 


Producing boundaries 

For this to work effectively, there had to be 
another element in the game: a boundary at the 
top and bottom of the screen. As the player hit 
the ball with the paddle, it could fly upwards. 

If there were nothing to stop it, then it would 
continue moving off the screen. Pong had an invisible top and bottom perimeter 
which would interact with the ball. Send the ball flying upwards and it would hit this 
boundary and come back into the field of play at another angle. This allowed the 
action to take place solely at the left and right edges of the game while introducing 
an extra dimension of unpredictability. “Pong was about seamless movement,” says 
Nolan. So all of this had to happen without the player really noticing what was 
happening behind the scenes. 

Good collision detection was crucial, and the developers had to define the 
height and width of the paddles. As the ball hit the paddle, the code needed to work 
out what to do with the ball by assessing the vertical and horizontal speeds. It did this 
by checking the position of the ball in relation to the paddle. It then needed to change 
the direction of the ball accordingly to send it back across the screen. 

Nolan says the original Pong code also had to take something else into 
account: “It needed to consider the reaction time from the controls to where there 
was a screen response. Tiny delays made a difference.” This 
is because Pong was designed to be fast-paced, so the response 
had to be as speedy as possible so that the player could react 
quickly to what is occurring on the screen. Too much of a 
delay would lead to immense frustration. Pong's developers 
needed the controls to be responsive. Handing a game to the 
opponent is not fun. 

Keeping score 

With all of this in place, the developers could look at the 
scoring system, which was relatively simple. The idea was 
that each time a player missed the ball and allowed it to go 
behind their paddle, the opposing player was given a point. In 
Pong , the game ended when one of the players reached eleven 
points, and this was an important aspect of games from that 
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time period. Since the coin-operated machines on 
which Pong ran required players to insert coins, 
there had to be a level at which the game could be 
won, otherwise someone would be able to pump in 
a single payment and enjoy the game all day 

“We had a limit in the coin-op because the 
game needed to average three minutes or less,” 
explains Nolan. This was typical of arcade games 
at the time: the idea was to allow gamers to play for 
just enough time to feel satisfied. If they lost, they 
could make a further payment or they could give 
someone else the chance to have a go. 

Moving on 

After creating Pong , Nolan’s career went from strength to 
strength. Atari launched the Video Computer System (VCS) 
console in 1977, which proved hugely successful in introducing 
gaming into people’s homes and cemented the company’s 
place in history, selling more than 30 million units. Nolan left 
a year later and concentrated on the Chuck E. Cheese Pizza 
Time Theatre which he had founded in his bid to put video 
games into family-friendly venues, in this case a restaurant. 
Nolan also produced personal entertainment robots and 
founded the digital entertainment company uWink in 2000: 
“I believed that there was a huge market opportunity in the 
social gaming space.” 

Today, Atari may not be the force it once was 
(although it’s making a comeback with a new console), but 
Nolan is regarded as one of the most important people in 
video game history. He heads up an educational software company called BrainRush 
and he has long been inducted into the Video Game Hall of Game. Thanks to Pong , 
his legacy has been well and truly cemented. 

Remaking the game 

When it comes to making your own To/zg-style tennis 
game, you can be creative and add your own touches. 

For instance, you could mix things up a bit by allowing 
gamers to move the paddle more freely around the 
screen to chase the ball in more complex ways. But do 
think carefully about the type of controller you use, 
whether it be a gamepad, joystick, rotary knob paddle, 
or keyboard. 

When it comes to the scoring system, you could set 
up the playing area to test whether or not the ball is 
passing through the section immediately behind the 
area where the paddle moves up and down. If this 
happens, then the code works out which side — left or 


Top tips 

• Nolan BushneLL says 
you should make sure 
the difficulty increases 
as the number of 
volleys increases. 

• He also says you 
should try to always 
make the most 
beneficial offensive 
shot have the highest 
probability of a miss. 


4 Atari co-founder 
Nolan BushneLL 
knows the value 
of addictive 
gameplay and 
simple rules 

5 The original Pong 
coin-op featured 
monochrome 
graphics 

6 Fifty variants 
of Pong were 
included in Video 
Olympics for the 
Atari 2600 
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7 Atari’s Home 
Pong console was 
released in 1975 


right - has been breached, telling the computer 
to make a noise and then adding a point to the 
player operating the opposing paddle. 

All you need to keep in mind is how players 
achieve a win. While you don’t have to worry 
about inducing players to feed coins into an 
arcade machine, it is still worth having a cut¬ 
off point. With this in place, you can turn your 
attention to creating an end-game, which kicks 
in when either player has reached the desired 
points total. This could be accompanied by 
another sound, perhaps some music to indicate that you have 
a winner. You could also program in some sounds whenever 
the ball hits the paddle to lend some added atmosphere. 

Besides adding 
sound effects, you can jazz up the graphics 
in any way you want. The limitations of 
early technology meant the original Pong was 
monochrome, but you don’t have to stick with 
that. (“We actually didn’t have colours available 
in the coin-op version when we started,” recalls 
Nolan. “The colours on the home Pong consoles 
were also difficult to activate.”) Your computer 
will have no such issues, so include colour, 
perhaps change the background from black to 
something else, and bring this old game into the 
21 st century with some flair. 

You can really have fun, with little flourishes at set stages in the play — perhaps 
when a player goes five points clear or if the player achieves the top number of points 
against an opponent scoring nothing - and you can also think about adding extras. 
“Make changes that make it more fun for yourself,” advises Nolan. “Programming a 
game for fun is the best way to learn.” 

Pong was actually used in just this way when the games industry was in its 
infancy. Atari’s 1976 release Breakout , for example, which has a paddle running along 
the bottom of the screen from left to right and asks players to destroy bricks with 


The beauty of Pong is 
that it teaches some 
great fundamentals 
of gameplay and 
collision detection 


How to control the game 

Instead of joysticks and joypads, Pong used a paddle.This had at least one fire button and a round 
wheel which was used to control the movement of the on-screen action. Pong was pioneering in that 
it was the first to use such paddles. One of the easiest ways to play around with a paddle controller 
is to look on eBay for old Atari 2600 paddles and buy an adapter to allow it to be connected to a 
computer via USB (one is available at 2600-daptor.com). You could also seek to make one of your 
own if you are a dab hand at electronics. Of course, you can control the game with a traditional 
gamepad and keyboard keys too. Explore the different methods to get a good feel for how they 
potentially affect the game. 
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a bouncing ball, was based on Pong. Taito’s Arkanoid later added power-ups to the 
Breakout concept and varied the levels and the types of bricks used. “As programmers 
feel confident and go beyond the basics, they can use the Pong engine to move from 
Pong to Breakout or Arkanoid — a Japanese rip-off,” says Nolan. 

The beauty of Pong is that it teaches some great fundamentals of gameplay and 
collision detection and it touches on some complex coding. It’s a great introduction 
to coding which allows you to play around and expand upon the concept once you 
have grasped it. 



































Coding Today 



T o show how a game like Pong can be 
coded, we've created Boing! using Pygame 
Zero, a beginner-friendly tool for making 
games in Python. It’s a good starting 
point for learning how games work — it 
takes place on a single screen without 
any scrolling, there are only three moving objects in the 
game (two bats and a ball), and the artificial intelligence 
for the computer player can be very simple — or even non¬ 
existent, if you’re happy for the game to be multiplayer 
only In this case, we have both single-player and two- 
player modes. 

The code can be divided into three parts. First, 
there’s the initial startup code. We import from other 
Python modules so we can use their code from ours. Then 
we check to make sure that the player has sufficiently up- 
to-date versions of Python and Pygame Zero. We set the 
WIDTH and HEIGHT variables, which are used by Pygame 
Zero when creating the game window. We also create two 
small helper functions which are used by the code below. 


Download the code 

Download the fully commented Boing! game code, along with all 
the graphics and sounds,from wfmag.cc/CTCl-boing 
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The next section is the largest. We create four classes: Impact, Ball, Bat, and 
Game. The first three classes inherit from Pygame Zero's Actor class, which amongst 
other things keeps track of an object’s location in the game world, and takes care of 
loading and displaying sprites. Bat and Ball define the behaviour of the corresponding 
objects in the game, while Impact is used for an animation which is displayed briefly 
whenever the ball bounces off something. The Game class’s job is to create and keep 
track of the key game objects, such as the two bats and the ball. 

Further down, we find the update and draw functions. Pygame Zero calls these 
each frame, and aims to maintain a frame rate of 60 frames per second. Gameplay 
logic, such as updating the position of an object or working out if a point has been 
scored, should go in update, while in draw we tell each of the Actor objects to draw 
itself, as well as displaying backgrounds, text, and suchlike. 

Our update and draw functions make use of two global variables: state and 
game. At any given moment, the game can be in one of three states: the main menu, 
playing the game, or the game-over screen. The update and draw functions read the 
state variable and run only the code relevant to the current state. So if state is 
currently State.MENU, for example, update checks to see if the SPACE bar or the 
up/down arrows are pressed and updates the 
menu accordingly, and draw displays the menu 
on the screen. The technical term for this kind 
of system is ‘finite state machine’. 

The game variable references an instance 
of the Game class as described above. The 

_init_(constructor) method of Game optionally 

receives a parameter named controls. When we 
create a new Game object for the main menu, we 


The Game class's 
job is to create and 
keep track of the key 
game objects 


Stepping through time 

The ball starts moving at five pixels 
per frame and speeds up by one pixel 
per frame each time it hits a bat.The 
simplest way of dealing with an object’s 
speed is to simply update its position 
by the desired distance each frame. 

However, there can be some issues 
with this, especially when an object 
is moving very fast. Let’s say the ball 
is moving horizontally at ten pixels 
per frame and is about to hit a bat which is two pixels away. If we update the ball’s position by ten 
pixels, it’s going to have gone eight pixels further than it should have done. In some games, this kind 
of issue can lead to objects passing right through each other, or through walls, when travelling very 
fast.There are a number of ways to deal with this - the approach we’ve taken here (and in other 
games in this book) is to break down the movement of the ball into a series of small steps, checking 
for collisions after each step. For a complex game with many moving objects, this kind of approach 
can be inefficient, but for a simpler game like this it’s ideal. 
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don t provide this parameter and so the game will therefore run m attract mode - m 
other words, while you’re on the main menu, you’ll see two computer-controlled 
players playing against each other in the background. When the player chooses to 


Challenges 


■ The Game class contains an attribute ai.offset, 
which is changed to a random value each time the 
ball bounces off a bat. Can you work out what this is 
for? Try changing the arguments given to random, 
randint and see what happens. What if you keep it 
fixed at zero,then start a new game and don’t touch 
the controls? 


■ There are several ways you can make the game easier 
or harder - how many can you think of? 


■ We use Python’s math. hypot function to calculate 
the length of a vector. Which famous mathematical 
theorem does this make use of? See if you can work it 
out yourself before you Google it! 


■ In the downloadable code (wfmag.cc/CTCl-boing), 
we’ve included an alternative, more advanced Al 
system. Can you work out how to enable it? 


start a new game, we replace the existing Game 
instance with a new one, initialising it with 
information about the controls to be used for 
each player - if the controls for the second 
player are not specified, this indicates that the 
player has chosen a single-player game, so the 
second will be computer-controlled. 

Two types of movement 

In Boing /, the Bat and Ball classes inherit from 
Pygame Zero’s Actor class, which provides 
a number of ways to specify an object’s 
position. In this game, as well as games in 
later chapters, we’re setting positions using 
the x and y attributes, which by default specify 
where the centre of the sprite will be on the 
screen. Of course, we can’t just set an object’s 
position at the start and be done with it — if 
we want it to move as the game progresses, we 
need to update its position each frame. In the 
case of a Bat, movement is very simple. Each 
frame, we check to see if the relevant player 
(which could be a human or the computer) 
wants to move — if they do, we either 
subtract or add 4 from the bat’s Y coordinate, 


I for one welcome our new Al overlords 

In single-player mode, the movement of the second bat is determined by calling the ai method in the Bat class. 
There are many ways to approach artificial intelligence, even for a game as simple as Boing!. At the simplest 
level, the Al could simply make the computer player try to exactly follow the movement of the ball (while 
taking into account the maximum speed the bat is allowed to move). At the most advanced level, cutting-edge 
machine learning could be employed - but that’s way 
beyond the scope of this book. In this game, the Al 
we’ve written is one small step up from the simplest 
system described above. When the ball is far away 
from the bat, the Al keeps the bat at the centre of the 
screen on the Y axis - ready for the ball to go either 
above or below it - but as the ball gets closer, the Al 
increasingly takes its position into account.This reflects 
the idea that as the ball gets closer, we have a better 
idea of where it's going to end up. 
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depending on whether they want to move up or 
down. We also ensure that the bat does not go 
off the top or bottom of the screen. So, not only 
are we only moving along a single axis, our Y 
coordinate will always be an integer (i.e. a whole 
number). For many games, this kind of simple 
movement is sufficient. Even in games where 
an object can move along both the X and Y 
axes, we can often think of the movement along 
each axis as being separate. For example, in the 
next chapter’s game, Cavern , the player might 
be pressing the right arrow key and therefore 
moving along the X axis at 4 pixels per frame, 
while also moving along the Y axis at 10 pixels 
per frame due to gravity. The movement along 
each axis is independent of the other. 


Figure l 



dx and dy represent a direction vector.The ball 
will move 1 pixel to the right and half a pixel 
down each time it moves.This vector can also 
be written as (1,0.5) 


Able to move at any 
angle, the ball needs 
to move at the same 
speed regardless of 
its direction 


Figure 2 



For the Ball, things get a bit more 
complicated. Not only can it move at any angle, 
it also needs to move at the same speed regardless 
of its direction. Imagine the ball moving at one 
pixel per frame to the right. Now imagine trying 
to make it move at a 45° angle from that by 
making it move one pixel right and one pixel up 
per frame. That’s a longer distance, so it would 
be moving faster overall. That’s not great, and 
that’s before we’ve even started to think about 
movement in any possible direction. 

The solution is to make use of vector mathematics and trigonometry. In the 
context of a 2D game, a vector is simply a pair of numbers: X and Y There are 
many ways in which vectors can be used, but most commonly they represent positions 
or directions. 

You’ll notice that the Ball class has a pair of attributes, dx and dy. Together 
these form a vector representing the direction in which the ball is heading. If dx and 
dy are 1 and 0.5, then each time the ball moves, it’ll move by one pixel on the X axis 


However, direction vectors should always be unit vectors 
- they should have a length of 1 unit (in the case of this 
game, 1 unit is 1 pixel).The black (1,0) vector is 1 unit 
long, but the orange (1,0.5) vector is approximately 1.12 
units long. Dividing the x and y components of a vector 
by the vector’s length gives a unit vector - this is known 
as normalisation, hence the function normalised. Doing 
this for the vector (1,0.5) gives approximately (0.89,0.45) - 
shown above by the green vector. 
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and a half a pixel on the Y axis. What does it mean to move half a pixel? When a 
sprite is drawn, Pygame Zero will round its position to the nearest pixel. So the end 
result is that our sprite will move down the screen by one pixel every other frame, and 
one pixel to the right every frame (Figure 1). 

We still need to make sure that our object moves at a consistent speed 
regardless of its direction. What we need to do is ensure that our direction vector is 
always a ‘unit vector’ - a vector which represents a distance of one (in this case, one 
means one pixel, but in some games it will represent a different distance, such as one 
metre). Near the top of the code you’ll notice a function named normalised. This 
takes a pair of numbers representing a vector, uses Python’s math.hypot function to 
calculate the length of that vector, and then divides both the X and Y components of 
the vector by that length, resulting in a vector which points in the same direction but 
has a length of one (Figure 2). 

Vector maths is a big held, and we’ve only scratched the surface here. You can 
find many tutorials online, and we also recommend checking out the Vector2 class in 
Pygame (the library on top of which Pygame Zero is built). 
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How to run the game 

Open the boing.py file in a Python editor, such as IDLE, and select Run > Run Module. 
For more details, see the ‘Setting up’section on page 186. 


Download the code 


001. 
002 . 
003 . 
004 . 
005 . 
006 . 
007 . 
008 . 
009 . 
010 . 
011 . 
012 . 
013 . 
014 . 
015 . 
016 . 
017 . 
018 . 
019 . 
020 . 
021 . 
022 . 
023 . 
024 . 
025 . 
026 . 
027 . 
028 . 
029 . 
030 . 
031 . 
032 . 
033 . 
034 . 
035 . 
036 . 
037 . 
038 . 
039 . 


import pgzero, pgzrun, pygame 
import math, sys, random 
from enum import Enum 

if sys.version_info < (3,5): 

print("This game requires at least version 3.5 of Python. Please download" 
"it from www.python.org") 
sys.exit() 

pgzero_version = [int(s) if s. isnumeric() else s 

for s in pgzero._version_. split ('.')] 

if pgzero_version < [1,2]: 

print("This game requires at least version 1.2 of Pygame Zero. You are" 

"using version {pgzero._version_}. Please upgrade using the command" 

"'pip install —upgrade pgzero'") 
sys.exit() 

WIDTH = 800 
HEIGHT = 480 
TITLE = "Boing!" 

HALFJVIDTH = WIDTH // 2 
HALF.HEIGHT = HEIGHT // 2 
PLAYER.SPEED = 6 
MAX_AI_SPEED = 6 

def normalised(x, y): 

length = math. hypot(x, y) 
return (x / length, y / length) 

def sign(x): 

return -1 if x < 0 else 1 

class Impact(Actor) : 

def _init_ (self, pos): 

super() . __init_ ("blank", pos) 
self. time = 0 

def update(self ): 
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040 . 
041 . 
042 . 
043 . 
044 . 
045 . 
046 . 
047 . 
048 . 
049 . 
050 . 
051 . 
052 . 
053 . 
054 . 
055 . 
056 . 
057 . 
058 . 
059 . 
060 . 
061 . 
062 . 
063 . 
064 . 
065 . 
066 . 
067 . 
068 . 
069 . 
070 . 
071 . 
072 . 
073 . 
074 . 
075 . 
076 . 
077 . 
078 . 
079 . 
080 . 
081 . 
082 . 
083 . 
084 . 
085 . 
086 . 


self. image = "impact" + str(self.time // 2) 
self. time += 1 

class Ball(Actor): 

def _init_ (self, dx): 

superQ. _init_ ("ball", (0,0)) 

self .x, self .y = HALF.WIDTH, HALF.HEIGHT 
self.dx, self.dy = dx, 0 
self. speed = 5 

def update(self ): 

for i in range(self.speed): 
original_x = self.x 
self.x += self.dx 
self.y += self.dy 

if abs(self.x - HALF_WIDTH) >= 344 and abs(original_x - HALF_WIDTH) < 344: 
if self.x < HALFJVIDTH: 
new_dir_x = 1 
bat = game.bats[0] 
else: 

new_dir_x = -1 
bat = game.bats [1 ] 

difference_y = self.y - bat.y 

if difference_y > -64 and difference_y < 64: 
self.dx = -self.dx 
self.dy += difference_y / 128 
self.dy = min(max(self.dy, -1), 1) 
self.dx, self.dy = normalised(self .dx, self.dy) 
game.impacts. append(Impact((self.x - new_dir_x * 10, self.y))) 
self. speed += 1 

game.ai_offset = random. randint(-1 0, 10) 
bat.timer = 10 

game.play_sound("hit" , 5) 
if self. speed <= 10: 

game.play_sound("hit_slow", 1) 
elif self. speed <= 12: 

game. play_sound("hit_medium" , 1 ) 
elif self. speed <= 16: 

game.play_sound("hit_fast", 1) 
else: 

game.play_sound("hit_veryfast", 1 ) 
if abs(self.y - HALF.HEIGHT) > 220: 
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087 . 
088 . 
089 . 
090 . 
091 . 
092 . 
093 . 
094 . 
095 . 
096 . 
097 . 
098 . 
099 . 
100 . 
101 . 
102 . 

103 . 

104 . 

105 . 

106 . 

107 . 

108 . 

109 . 

110 . 
Ill . 
112 . 

113 . 

114 . 

115 . 

116 . 

117 . 

118 . 

119 . 

120 . 
121 . 
122 . 

123 . 

124 . 

125 . 

126 . 

127 . 

128 . 

129 . 

130 . 
131 . 

132 . 

133 . 


self.dy = -self.dy 
self.y += self.dy 

game.impacts. append(Impact(self .pos)) 
game. play_sound("bounce" , 5) 
game. play_sound("bounce_synth" , 1 ) 

def out(self): 

return self.x < 0 or self.x > WIDTH 
class Bat(Actor): 

def _init_ (self, player, move_func=None) : 

x = 40 if player == 0 else 760 
y = HALF.HEIGHT 

super() . __init_ ("blank" , (x, y)) 

self. player = player 
self. score = 0 

if move_func != None: 

self .move_func = move_func 
else: 

self .move_func = self.ai 

self. timer = 0 

def update(self ): 
self. timer -= 1 
y_movement = self .move_func() 
self.y = min(400, max(80, self.y + y_movement)) 

frame = 0 
if self. timer > 0: 
if game.ball. out(): 

frame = 2 
else: 

frame = 1 

self. image = "bat" + str(self. player) + str(frame) 
def ai(self): 

x_distance = abs(game.ball.x - self.x) 
target_y_1 = HALF.HEIGHT 
target_y_2 = game.ball.y + game.ai_offset 
weightl = min(1 , x_distance / HALF_WIDTH) 
weight2 = 1 - weightl 

target_y = (weightl * target_y_1) + (weight2 * target_y_2) 
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134 . 

135 . 

136 . 

137 . 

138 . 

139 . 

140 . 
141 . 

142 . 

143 . 

144 . 

145 . 

146 . 

147 . 

148 . 

149 . 

150 . 
151 . 

152 . 

153 . 

154 . 

155 . 

156 . 

157 . 

158 . 

159 . 

160 . 
161 . 
162 . 

163 . 

164 . 

165 . 

166 . 

167 . 

168 . 

169 . 

170 . 
171 . 

172 . 

173 . 

174 . 

175 . 

176 . 

177 . 

178 . 

179 . 

180 . 


return min(MAX_AI_SPEED, max(-MAX_AI_SPEED, target_y - self.y)) 
class Game: 

def _init_ (self, controls=(None, None)): 

self. bats = [Bat(0, controls[0]), Bat(1 , controls[1])] 
self .ball = Ball(-1 ) 
self. impacts = [] 
self .ai_offset = 0 

def update(self ): 

for obj in self. bats + [self. ball] + self .impacts: 

obj. update() 

for i in range(len(self.impacts) - 1, -1, -1): 

if self .impacts[i].time >= 10: 
del self .impacts[i] 

if self. ball.out(): 

scoring_player = 1 if self. ball.x < WIDTH // 2 else 0 

losing_player = 1 - scoring_player 

if self .bats[losing_player].timer < 0: 
self .bats[scoring_player].score += 1 
game. play_sound("score_goal" , 1 ) 
self .bats[losing_player].timer = 20 

elif self .bats[losing_player].timer == 0: 

direction = -1 if losing_player == 0 else 1 
self. ball = Ball(direction) 

def draw(self): 

screen. blit("table" , (0,0)) 

for p in (0,1): 

if self .batsEp].timer > 0 and game.ball. out(): 
screen. blit("effect M + str(p), (0,0)) 

for obj in self. bats + [self. ball] + self .impacts: 

obj .drawQ 

for p in (0,1): 

score = "{0:02d}" .format(self.batsEp].score) 

for i in (0,1): 
colour = "0" 
other_p = 1 - p 
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181 . 
182 . 

183 . 

184 . 

185 . 

186 . 

187 . 

188 . 

189 . 

190 . 
191 . 

192 . 

193 . 

194 . 

195 . 

196 . 

197 . 

198 . 

199 . 

200 . 
201 . 
202 . 

203 . 

204 . 

205 . 

206 . 

207 . 

208 . 

209 . 

210 . 
211 . 
212 . 

213 . 

214 . 

215 . 

216 . 

217 . 

218 . 

219 . 

220 . 
221 . 
222 . 

223 . 

224 . 

225 . 

226 . 
227 . 


if self .bats[other_p].timer > 0 and game.ball. out(): 

colour = "2" if p == 0 else "1" 
image = "digit" + colour + str(score[i]) 
screen. blit(image, (255 + (160 * p) + (i * 55), 46)) 

def play_sound(self , name, count=1): 

if self .bats[0].move_func != self .bats[0].ai: 
try: 

getattr(sounds, name + str(random. randint(0, count - 1))).play() 
except: 
pass 

def p1_controls() : 
move = 0 

if keyboard.z or keyboard.down: 

move = PLAYER.SPEED 
elif keyboard.a or keyboard.up: 

move = -PLAYER.SPEED 
return move 

def p2_controls() : 
move = 0 
if keyboard.m: 

move = PLAYER.SPEED 
elif keyboard.k: 

move = -PLAYER.SPEED 
return move 

class State(Enum): 

MENU = 1 
PLAY = 2 
GAME.OVER = 3 
num_players = 1 
space_down = False 

def updateQ: 

global state, game, num_players, space_down 

space_pressed = False 

if keyboard.space and not space_down: 

space_pressed = True 
space_down = keyboard.space 

if state == State.MENU: 
if space_pressed: 
state = State.PLAY 
controls = [pi.controls] 

controls. append(p2_controls if num.players == 2 else None) 
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228 . game = Game(controls) 

229 . else: 

230 . if num_players == 2 and keyboard.up: 

231 . sounds.up. play() 

232. num_players = 1 

233. elif num_players == 1 and keyboard.down: 

234 . sounds.down. play () 

235 . num_players = 2 

236 . 

237 . game. updateQ 

238 . 

239 . elif state == State.PLAY: 

240 . if max(game.bats[0]. score, game.bats[1].score) > 9: 

241 . state = State.GAME.OVER 

242 . else: 

243 . game. updateQ 

244 . 

245 . elif state == State.GAME_0VER: 

246 . if space_pressed: 

247. state = State.MENU 

248 . num_players = 1 

249 . game = GameQ 

250 . 

251 . def drawQ : 

252 . game.draw() 

253 . 

254 . if state == State.MENU: 

255 . menu_image = "menu" + str(num_players - 1) 

256 . screen. blit(menu_image, (0,0)) 

257 . 

258 . elif state == State.GAME.OVER: 

259 . screen. blit("over" , (0,0)) 

260 . 

261 . try: 

262 . pygame.mixer .quit() 

263 . pygame.mixer. init(441 00, -16, 2, 1024) 

264 . 

265 . music. play ("theme" ) 

266 . music.set_volume(0.3) 

267 . except: 

268 . pass 

269 . 

270. state = State.MENU 

271 . game = GameQ 

272 . 

273 . pgzrun.goQ 
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3 




1 The background 
needs to be not 
too busy, so the 
ball stays visible 

2 Colour-coded 
overlays appear 
when a point is 
won by either side 

3 The ball sprite 
is simple; its 
movement is not 


4 



Each bat has 
three versions: 
normal, with 
shadow (when a 
point is lost), and 
hitting the ball 
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5 The title screen 
offers a choice 
of one- or two- 
player mode 

6 Digits used to 
show the scores, 
colour-coded for 
each player 

7 There are five 
impact sprites 
numbered o to 4 


6 □ 

1 

2 

3 

4 

5 

7 

a 

3 
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Chapter 2 

Action Platformer 


Enduringly popular, the platform 
game genre is still packed with 
creative possibilities 



P latformers involve moving a character 
around a series of obstacle-strewn 
platforms, jumping, shooting, and 
avoiding any baddies along the way 
They can be played alone or with a 
friend: produced by Taito, Bubble Bobble 
was a tough (and incredibly popular) coin-op, two-player 
cooperative platformer which made a successful transition 
to home computers. It featured two brothers called Bubby 
and Bobby who had been turned into a pair of cuddly 
creatures, affectionately known as Bub and Bob, by the evil 
Baron Von Blubba. With their girlfriends kidnapped, 100 
levels of tricky, fast-paced action awaited them as they tried 
their hardest to rescue them, battling all manner of beasties 
along the way As the game’s name suggests, bubbles played 
a major role in the gameplay - you had to fire them at 
enemies to stun them, then pop them for the kill. Once a 
screen was cleared of rivals, it was time to advance to the 
next level. 


Inspiration 

Bubble Bobble was designed by Fukio Mitsuji, who also 
created an incredibly popular follow-up in Rainbow 
Islands. It was ported to many machines including the 
Commodore 64, where it was overseen by Stephen Ruddy, 
who worked on games such as Target: Renegade , FIFA 99, 
and MotoGP 09/10. Ruddy still works in gaming for Yippee 
Entertainment. Sadly, Mitsuji-san died on 11 December 
2008, aged 48. In the 1990s, he went on to put his skills as 
a game designer to good use by teaching coders new tricks. 
He also freelanced on titles including Magical Puzzle Popils 
on the Sega Game Gear. 
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Bubble Bobble 


Released 


Platforms 


1986 


Arcade 

Game Boy 

Commodore 64 

Game Boy Color 

ZX Spectrum 

PlayStation 

Amiga 

Sega Saturn 

Atari ST 

NES 

MSX 2 

SNES 

Amstrad CPC 

Game Gear 

Sharp X68000 


PC 


Apple II 


FM Towns Marty 


Sega Master System 
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Like many classic games of the past, Bubble Bobble originated in the arcades and was 
later made available on many other machines. 


Other Notables 


Donkey Kong / Mario / Prince of Persia 


There are games where you can choose weapons of devastating effectiveness. Gravity 
guns, magical swords, BFGs, and frag grenades are all fine choices. There’s no doubt 
that each one of these has the potential to inflict damage on foes, making them highly 
effective in combat. But what if there was no choice? What if the only thing you 
had to hand was merely a bubble — yes, a simple thin him of soapy water filled with 
air? As daft as that may sound, one game of the 1980s made use of just that. Its 
name? Bubble Bobble. 

Anyone who has been lucky enough to have some fun with this iconic 1986 
arcade platformer will understand just how effective bubbles can be. They would be 
used to trap enemies and, when burst, dispatch them with ease. With a bit of finesse, 
multiple bubbles could get rid of enemies at once for extra points. And later in the 
game, they come into their own as temporary - and occasionally deadly - Boating 
platforms to get the player from level to level. 

The game’s designer, Fukio Mitsuji, was looking for something new. Back in 
the 1980s, platformers were a strong staple of gaming, making up a large (and often 
homogeneous) slice of the industry. Developers like Mitsuji realised that they needed 
to create something which made their title stand out. In the case of Bubble Bobble , two 
kawaii characters called Bub and Bob were introduced, and the action took place 
over 100 static screens. Despite its simple premise, the game proved highly addictive 
and also rather complex. 

Gameplay was compulsive and kept players coming back for more. The 
wobbly action of the bubbles themselves, which acted as weapons and as (fiendishly 
tricky) temporary platforms to jump off, was unpredictable. There were hidden 
bonuses and power-ups, and different ways of seeing enemies off (special bubbles 
could be produced which, when burst, would attack foes with water, lightning, or 
fire). A stage would be cleared when all of the enemies were destroyed, but the 
difficulty level increased the further you progressed. And there was clarity for the 
player: the basic structure of the game remained the same from start to hnish, 
following the same genre-dehning rules laid down by Space Panic at the beginning 
of the decade. 

Platform jumping 

In general, platformers offered players the opportunity to jump around an 
environment strewn with platforms, with obstacles to avoid and enemies to slay. One 
of the most popular was Donkey Kong , which starred Mario — or Jumpman as he was 
known back then. Over time, platformers were married up with other genres such as 
beat-’em-ups and adventures. 

But even at their purest, they often proved compelling. Developers would seek 
to inject their own little twists to the gameplay, introducing new and original concepts. 
Nintendo’s 1983 arcade game Mario Bros, introduced two-player simultaneous 
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cooperative play, a concept which Bubble Bobble emulated. “In this game, you had to 
play cooperatively in order to reach the true ending,” said Mitsuji. 

Bubble Bobble was Mitsuji’s first game. He developed it for Taito, a coin-op 
game manufacturer which had achieved huge success in 1978 with the launch of 
Space Invaders , although it had made other titles prior to that, including Speed Race in 
1974. With games such as Qix in 1981 and Elevator Action in 1983 under its belt, Taito 
had built a solid reputation. It was always on the lookout for games that would get 
players pumping coin after coin into its machines. Bubble Bobble brought with it the 
right mixture of innovation and addictiveness. 

Mitsuji put his game’s enduring popularity down to Bub and Bob, but he also 
said the unique ability to shoot bubbles was a major attraction for gamers looking for 
something new (his desire to innovate was so strong, he was adamant that he would 
never produce a direct sequel). The fact that it was 
an arcade game meant it also needed to be accessible 
and easy to learn. For that reason, it came with little 
in the way of razzmatazz, preferring to let the game 
speak for itself. This aspect was also ported to the home 
computer versions. 

Stephen Ruddy was responsible for the 
Commodore 64 port, which he created while working 
for Software Creations. At the time, the publisher and 
developer was based above a computer shop opposite 
the BBC’s North West studios on Oxford Road in 
Manchester, and Stephen had been offered a job after 
responding to an advertisement in the Manchester Evening News. It was his task to 
identify the structure of the game and re-code it. 

“The basic structure of games is that you have a front-end and a back¬ 
end,” he explains. “The front-end is normally made up of some kind of attract 
mode [that is, something to draw the player to the game and excite them] and the 
user interface that sets up the game. The back-end is normally a game manager 
that manages some user interface, a bunch of game objects, and an environment 
they operate in. Being an arcade game, Bubble Bobble had very little in the way of 
a front-end. A title screen, an attract loop, and a high-score table were about all 
it contained.” 

By concentrating on the back-end, Mitsuji aimed to eliminate any wasteful 
preamble that would otherwise slow down the speed at which player coins would 
be deposited into the slot. It meant he could focus on the game manager. “The 
manager essentially concentrated on the lives of the player — three in the case 
of Bubble Bobble — as well as the introduction user interface and the game cycle,” 
Stephen continues. 

Non-scrolling screen 

Since all of the action in Bubble Bobble took place on a series of single, non-scrolling 
screens, it was much easier for developers such as Stephen to replicate it on home 
computers and consoles. It removed the need for a scene management system, for 
example, because with such a small environment, there was only a need for a limited 
number of objects. 


The unique ability to 
shoot bubbles was a 
major attraction for 
gamers looking for 
something new 
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The objectives 

Short term: Enjoy yourself. Stephen Ruddy says the biggest thing is the sheer creative enjoyment of 
the whole process - you start with nothing every time. So work on the basics. 

Medium term: Start building up the levels. Have fun with the level design and see what designs you 
come up with. 

Long term: Begin to think about what else you will be able to throw into the mix. Once you move 
beyond simple 2D sprites, rendering with complex shaders and 3D-skinned meshes is an interesting 
and rewarding area for games designers. 


“A scene management system is complex, but it is only needed if you have 
a large environment with potentially many thousands of game objects,” Stephen 
explains. “It will identify and update only those objects that need to be updated and 
it will only render the objects that are on screen. Likewise, it will only collide the 
relevant collision primitives. 

“With a single-screen system and a limited number of objects, none of this 
is required. You can simply assume all objects must be updated and all objects must 
be rendered. The objects can also take on collision themselves rather than have a 
separate physics/collision/collision-resolution system of some kind or other.” 

Bubble Bobble had many objects. There were Bub and Bob themselves of 
course, but there was also a variety of weapons. Aside from the bubbles themselves, 
players would have to dodge fireballs, water drops, fire, lightning, rocks, and bombs. 
They also had to avoid the enemies, with baddies made up of robots, ghosts, 
whales, teddies, springs, bugs, dwarves, invaders, and a boss. In addition, there were 
collectables such as fruit, bonuses, and power-ups. 

“With some games the environment can be stunningly complex and may well 
be made up of games objects itself, but in Bubble Bobble the environment was a simple 
2D tiled map with several environmental effects attached,” says Stephen. “In Bubble 
Bobble’s case the tiled map was really just collision data, a flag to indicate whether it 
contained a platform or not, and an ‘airflow’ direction setting to indicate which way 
bubbles should float through the time (0—3 for up, down, left, right).” 


Blowing bubbles 

Of all of these objects, the bubbles were the most important. A lot of time and 
attention was paid to this mechanic to ensure they behaved in the way the player 
expected. When a bubble was spawned by the player, it would be given a specific 
horizontal velocity. Crucially, it would also include a “baddie collision lifetime” 
which indicated how long an enemy could remain in a bubble before it popped 
itself and allowed them to escape. There was also a total lifetime setting to prevent 
the bubble from lingering for too long. 

“When the player fired a bubble, it would take care 
1 A1986 flyer for of itself, travelling horizontally as configured and changing to 
release^the rear a ca P ture( ^ baddie’ bubble if it touched an enemy,” Stephen 
explained the explains. “The baddie setting would then match the baddie 

game mechanics it captured and it would check itself for a collision with the 
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player.” In other words, if a spiky part of the player - the back, head, or feet if the 
jump button was not pressed - touched the bubble, then it would pop. If it came into 
contact with the front of Bub or Bob, the bubble would simply be pushed along. The 
code would wait until one of these events happened and then act on it. 

The code would also know if there was no contact at all between the bubble 
and the enemies. “If the bubble never touched a baddie at the end of its collision 
lifetime, then it would change itself to a ‘float bubble’ which would simply drift along 
with the airflow as defined in the tile map,” says Stephen. It may sound complicated 
but, in essence, the coders were simply working out the interaction between the 
bubbles and both the player and enemy characters. 

“The player was only concerned with the actions the player could do (that is, 
movement and firing); the other objects took care of themselves, colliding with the 
player or each other,” Stephen continues. “So, for example, a bubble would test if 
it was in collision with the player and either pop or be pushed out of the way, and a 
baddie would test if it was in collision with the player and either kill the player or kill 
itself (if the player was invulnerable due to a power-up).” 

Figuring it out 

Since Stephen was porting a pre-existing arcade 
game, he and the team at Software Creations 
had no input into the design of the game. So, 
in order to get to grips with all of the various 
aspects of Bubble Bobble during the conversion, 
the developers had to play the game over and 
over again, noting all of the different nuances of 
the gameplay. It was then up to them to figure 
out the mechanics of the game and replicate it 
for the home market. 

Deep mechanics in the game, like a time 
limit on capturing an enemy, were a challenge 
to tease out. “‘Captured baddie’ bubbles would pop and release the baddie they 
contained, but the baddie that was released would be set in a ‘hurry up’ state,” 
explains Stephen. 

“This was visually different since it used a red colouring. The movement 
speed was also doubled. In later levels this was used as a driver to make the player 
plan when to fire a bubble and when to pop the baddies because the bubbles would 


Deep mechanics, 
like a time limit on 
capturing an enemy, 
were a challenge to 
tease out 


Learn from the master 

Stephen Ruddy offers some excellent advice for anyone looking to program their own games. 

Never fear: Stephen says you mustn’t be afraid of learning new skills or asking for help. 

Use your knowledge: The more techniques you master, the easier it will be when faced with 
something new. 

Know when to stop: When it’s finished it’s finished. You have to learn to ignore the temptation to 
rework your code and move on. 
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whizz off to specific areas of the screen.” Players also had to stay on their toes when it 
came to grabbing bonus letters, which had a finite lifetime too. Hazards like lightning, 
water, and fire had infinite lifetimes and had to be treated differently. 

All of this was a good learning curve for Stephen, who had only developed 
three previous games on the Commodore 64: Mystery of the Nile in 1986 and both 
Kinetik and The Big KO! the following year. But since Bubble Bobble was more complex 
than he first imagined, some mechanics were missed. “We weren’t aware of the rules 
regarding when the arcade game decided on which items appeared,” he says, “but we 
did figure out some simply by playing the game.” 

Bubble Bobble had a bonus collectable and a power-up collectable which 
appeared on every level. “The bonus collectable simply awarded the player points 
and it was selected by how quickly the player completed the previous level - the 
quicker the player completed the level, the better-scoring the bonus collectable would 
be. The power-up collectable was selected by a complex rule set which also reflected 
how the player completed the previous level. Today, these nuances are found on the 
internet, but in our conversions we noticed some but not others and ended up with a 
weighted default system.” 

Just as troublesome was the way in which players controlled the characters. In 
Bubble Bobble, Bub and Bob could move left and right and they could also jump. In the 
arcade version, there was a simple two-way joystick and two buttons to achieve this - 
one to jump and one to fire. In most home systems, joysticks did not have two-button 
setups, so a workaround had to be found in order to better replicate the experience 
on machines like the Commodore 64. 


“Controls are always the trickiest part of games development,” says 
Stephen. “Really there aren’t any short cuts, so you need to keep iterating over them 
until they ‘feel’ right. For the Commodore 64 version, the main issue was having 
one less button than the arcade machine. It made use of a four-way joystick as 
well as fire, as opposed to a two-way joystick together 


with jump and fire.” The solution was to use the 
up direction on the joystick as jump, but even then, 


Top tips 


movement in Bubble Bobble was more complicated than • Experiment with 

it first appeared. different bubbles.The 

“The player moved across platforms and was g ame had three 

obstructed by any solid tile cell blocking the player elemental 

character’s ‘feet’,” Stephen says. “But the logic for bubbles - lightning, 

moving sideways was different when not on a platform. water,and fire - that 

The player could move regardless if their character’s could destroy enemies 

‘feet’ were already embedded in a solid cell. Similarly, j n different ways, 

when falling, player characters would only land on 

platforms that had empty space about them.” • Consider a boss in your 

game so that when all 
of the creatures are 

Racking up the points defeated, there is a 

To keep players motivated, they could build a high monster of a challenge 

score as they made their way through the stages. When to be had that will 

an enemy was killed, for instance, it was turned into keep pLayers on their 

food which could then be collected for points. Many toes and add variety. 
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different items carried differing point values, which introduced a healthy dollop of 
strategy to the game. 

A green pepper had 10 points, for example, a turnip 60, a banana 500, and 
French fries 1000. There was beer at 4000 points, red jewels at 7000, and gold crowns 
at 10,000. There were also lots of associated triggers which could depend on how 
quickly you finished a previous stage. 

“The core competitive element of every arcade game is the player’s score 
and a high-score table: it’s the hook that keeps you returning back for one more 
go to improve on your own personal previous best and to be the best at the game,” 
says Stephen. “Today this has been extended with leaderboards, which incorporate a 
social aspect where you can see, challenge, and beat your friends’ scores as well as all 
the scores worldwide - it’s still a key driver that 
keeps players coming back to improve.” 

The two-player mode of the game was 
also crucial in hooking players in. Bubble Bobble 
could be played by one or two people, and it was 
the cooperative mode which made it such an 
enduring joy. Indeed, Mitsuji wanted Bubble Bobble 
to be a game that couples would enjoy playing 
together. He saw gaming as a hobby that anyone 
could enjoy, regardless of gender, and he wanted 
to encourage more female gamers in particular, 
since they were rarely seen in Japanese arcades. 

At times, it was almost as if Mitsuji had a 
bag of holding into which he was throwing ideas. 

You could collect letters that spelt ‘EXTEND’ to get an extra life, grab an umbrella 
and skip levels, or enter secret rooms and access hidden bonuses. There were even 
multiple endings. The first was a ‘bad’ ending for single players who only rescued 
Betty and not Patty, and told the gamer to “never forget your friend”. The good 
ending needed two players and it saved both Betty and Patty while unlocking a Super 
Mode which encouraged a replay of the game (obviously, to get players to pump in 
more coins). Once that was completed, Bub and Bob’s parents were finally revealed. 

“We didn’t implement the multiple endings of the arcade, simply because 
we weren’t aware of them,” admits Stephen. Thankfully, that didn’t ruin the 
attraction of the ported games. Virtually every home system has been blessed with 
the presence of Bub and Bob, either as a conversion of the original coin-op or in one 
of many spin-offs. 

The fact that the direct ports were still considered 
brilliant despite not being entirely faithful, shows that the core 
mechanics of Bubble Bobble could more than stand alone as a 
classic. Indeed, the only port that was accurate to a large degree 
was the Sega Master System version which Taito itself coded. 

But that’s not to say Taito had been miserly and kept the source 
code to itself for the other versions. On the contrary, it shared 
it with the developers of the other versions, but the comments 
were in Japanese, making it difficult for teams that didn’t speak 
the language to follow. 


2 After trapping 
enemies in 
bubbles, you 
still need to 
burst them 

3 A high score 
table is always 
a good way to 
make gamers 
competitive 


The core competitive 
element of every 
arcade game is the 
player's score and a 
high-score table 
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Adding complexity 

Although Bubble Bobblems a simple enough game to create - albeit challenging to pull off 
satisfactorily - there are many areas of game programming that become more complex the more 
your game relies on them.According to Stephen Ruddy, scene management becomes more important 
and entails breaking a large environment up into smaller more manageable pieces for updating or 
rendering. For larger 2D or 3D worlds this becomes essential. Similarly, he says: “Physics simulation, 
collision, and restitution in 2D and 3D can be very complex and reliant on probably the most complex 
mathematics you’ll come across in game development.” Enjoying these subjects is helpful, though not 
essential, for making games. And finally, he opines: “Audio is often overlooked as mostly people just 
play a sample when an event occurs. But software mixing, complex fading, and multi-track streaming 
may also be required if your game requires complex audio.” 


Still, it was a good learning curve for Stephen. “You 
never stop learning, so don’t be afraid of anything,” he advises. 
“You may be required to program something you’ve never 
done before, so you mustn’t be afraid of learning new skills 
or asking for help. The simple fact is that no one knows every 
methodology, algorithm, or technology as of course new ones 
are created, extruded, or manufactured all the time. Fortunately, 
the more you do get to grips with will reduce apprehension 
when faced with something new and unknown.” 


4 Bursting a 
water bubble 
releases a 
torrent that 
clears any 
enemies in 
its path 

5 Special 
power-ups such 
as lightning are 
useful on 

the trickier 
later levels 
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L ike Bubble Bobble , our game Cavern takes 
place on a single screen. Robot enemies are 
created just off the top of the screen, and 
fall into the level. The Player can fire Orbs 
— if a robot touches an orb, it will become 
trapped inside. The orbs pop either after 
four seconds, or when they reach the top of the screen. 
Robots can fire Bolts which can pop orbs or hurt the 
player. There are two types of robot: a standard type, and 
a more aggressive type which has the ability to deliberately 
fire at orbs. 


Download the code 

Download the fully commented Cavern game code, along with 
all the graphics and sounds, from wfmag.cc/CTCl-cavern 
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The Fruit class represents items the player can collect. Normally these items 
are, as the name suggests, pieces of fruit, which increase the player’s score. However, 
there are also pick-ups which increase the player’s health or give an extra life. Fruit 
pick-ups are dropped when an orb containing a robot reaches the top of the screen, 
and are also created in random positions every 100 frames. The extra health and 
extra life power-ups have a chance of being created when an orb containing the more 
aggressive type of robot is popped. 

Each of the classes mentioned above inherits from either CollideActor 
or GravityActor - CollideActor, which inherits from Pygame Zero’s Actor class, 
provides a move method which moves the object in the specified direction, but won’t 
allow it to go through walls. GravityActor inherits from CollideActor, and allows 
objects to be affected by gravity. 

The Game class maintains a reference to the player object, as well as lists of 
fruit, bolts, enemies, orbs, and pops (objects which display an orb’s popping animation 
- similar to Impact objects in Boingl). At the start of each level, the game object sets up 
the grid of blocks which will form the level, decides how many enemies of each type 
there will be on this level, and creates a randomly shuffled list of enemy types, which 
determines the order in which different enemy types will appear. 


Level with me 

Levels in Cavern are formed of blocks, each block being 25*25 pixels. At the top of the code you’ll 
see a list called levels, containing three further lists which correspond to the three level layouts in 
the game. Each level list contains 17 strings, where each string represents a row. Within each row, a 
space character means there’s no block at that position; any other character (we’ve used X) 
represents a block. An empty string indicates a row with no blocks. You might notice that the 
variable num_rows is 18, which doesn’t seem to match with the number of rows in the level lists. In 
the Game. next.ievei method, we add a copy of the first row to the end of the level data, so that the 
first and last rows are the same. 
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As with Boing!, the final part of the code uses a simple state machine system 
to update and draw the game objects. There are also functions for drawing text and 
the player’s score, health, and lives. 


Challenges 


■ In Bubble Bobble, bubbles don’t automatically burst when they reach the top of the screen - instead 
they float around and, if left long enough, enemies in bubbles can escape (and come back angrier, 
moving at an increased speed). The player can burst bubbles by walking, falling, or jumping into them. 
Bursting bubbles could also cause a chain reaction, bursting other nearby bubbles. How would you 
change the game to match this? 


■ Currently, holding the SPACE bar causes the player to blow an orb further across the level. What if 
instead of this, holding the SPACE bar caused the player to create a series of orbs in quick succession? 
To keep the game balanced, there are a number of other things you’d need to change, such as the 
total number, maximum on-screen number, and creation rate of enemies. 


Incomprehensible? 



You’ll sometimes see code similar to [x*2 for x in range(ie)].This makes use of a very useful 
Python feature known as list comprehension. In this case,the code generates the numbers 0 to 9, 
multiplies each one by two, and puts the resulting numbers in a list. In Cavern, we use this 
feature to remove objects from lists. For example,take the line self .enemies = [e for e in 
self .enemies if e. alive ].This creates a new list which consists of the entries from the existing 
self. enemies list, excluding those which are no longer alive.The new list then replaces the 
existing enemies list. Bear in mind that if there were any other variables besides self. enemies 
which referred to the same list, this technique wouldn’t affect those variables, and they would 
continue to refer to the old version of the list. In Cavern this isn’t an issue, and list comprehensions 
allow us to do in a single line what would otherwise take at least three lines. 
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How to run the game 

Open the cavern.py file in a Python editor,such as IDLE,and select Run > Run Module. 
For more details, see the ‘Setting up’section on page 186. 


Download the code 


001. 
002 . 
003 . 
004 . 
005 . 
006 . 
007 . 
008 . 
009 . 
010 . 
011 . 
012 . 
013 . 
014 . 
015 . 
016 . 
017 . 
018 . 
019 . 
020 . 
021 . 
022 . 
023 . 
024 . 
025 . 
026 . 
027 . 
028 . 
029 . 
030 . 
031 . 
032 . 
033 . 
034 . 
035 . 
036 . 
037 . 
038 . 
039 . 
040 . 


from random import choice, randint, random, shuffle 

from enum import Enum 

import pygame, pgzero, pgzrun, sys 

if sys.version_info < (3,5): 

print("This game requires at least version 3.5 of Python. Please download" 
"it from www.python.org") 
sys.exit() 

pgzero_version = [int(s) if s. isnumeric() else s 

for s in pgzero._version_. split ('.')] 

if pgzero_version < [1,2]: 

print("This game requires at least version 1.2 of Pygame Zero. You are" 

"using version {pgzero._version_}. Please upgrade using the command" 

"'pip install —upgrade pgzero'") 
sys. exit() 

WIDTH = 800 
HEIGHT = 480 
TITLE = "Cavern" 

NUM.ROWS = 18 
NUM.COLUMNS = 28 


LEVEL_X_OFFSET = 50 
GRID_BLOCK_SIZE = 25 

ANCHOR_CENTRE = ("center", "center") 
ANCHOR_CENTRE_BOTTOM = ("center", "bottom") 


LEVELS = [ [ 


XXXXX XXXXXXXX XXXXX", 

II II II II II II II 

xxxxxxx xxxxxxx 

xxxxxxxxxxxxxxxxxxxxxx 


xxxxxxxxx 

W"], 


XXXXXXXXX", 


XXXX XXXXXXXXXXXX XXXX", 


64 







Coding Today 

rauom 


041 . 
042 . 
043 . 
044 . 
045 . 
046 . 
047 . 
048 . 
049 . 
050 . 
051 . 
052 . 
053 . 
054 . 
055 . 
056 . 
057 . 
058 . 
059 . 
060 . 
061 . 
062 . 
063 . 
064 . 
065 . 
066 . 
067 . 
068 . 
069 . 
070 . 
071 . 
072 . 
073 . 
074 . 
075 . 
076 . 
077 . 
078 . 
079 . 
080 . 
081 . 
082 . 
083 . 
084 . 
085 . 
086 . 
087 . 


xxxxxxxxxxxxxxxxxxxx 


xxxxxx 


XXXXXX" 


V",.], 

XXXX XXXX XXXX XXXX" 

XXXXXXXX XXXXXXXX " 

XXXX XXXXXXXX XXXX" 

xxxxxx xxxxxx 

V ",. ]] 


def block(x,y): 

grid_x = (x - LEVEL_X_OFFSET) // GRID_BLOCK_SIZE 
grid.y = y // GRID_BLOCK_SIZE 
if grid_y > 0 and grid_y < NUM_R0WS: 
row = game.grid[grid_y] 

return grid_x >= 0 and grid_x < NUM_COLUMNS and len(row) > 0 and \ 
row[grid_x] != " " 

else: 

return False 
def sign(x): 

return -1 if x < 0 else 1 

class CollideActor(Actor) : 

def _init_ (self, pos, anchor=ANCHOR_CENTRE) : 

super(). _init_ ("blank", pos, anchor) 

def move(self, dx, dy, speed): 

new_x, new_y = int(self.x), int(self.y) 

for i in range(speed) : 

new_x, new_y = new_x + dx, new_y + dy 

if new_x < 70 or new_x > 730: 
return True 

if ((dy > 0 and new_y % GRID_BLOCK_SIZE == 0 or 
dx > 0 and new_x % GRID_BLOCK_SIZE == 0 or 
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088 . 
089 . 
090 . 
091 . 
092 . 
093 . 
094 . 
095 . 
096 . 
097 . 
098 . 
099 . 
100 . 
101 . 
102 . 

103 . 

104 . 

105 . 

106 . 

107 . 

108 . 

109 . 

110 . 
Ill . 
112 . 

113 . 

114 . 

115 . 

116 . 

117 . 

118 . 

119 . 

120 . 
121 . 
122 . 

123 . 

124 . 

125 . 

126 . 

127 . 

128 . 

129 . 

130 . 
131 . 

132 . 

133 . 

134 . 


dx < 0 and new_x % GRID_BLOCK_SIZE == GRID_BL0CK_SIZE-1 ) 
and block(new_x, new_y)): 
return True 

self.pos = new_x, new_y 
return False 

class Orb(CollideActor) : 

MAX.TIMER = 250 

def _init_ (self, pos, dir_x): 

super() . __init_ (pos) 

self .direction_x = dir_x 

self .floating = False 

self .trapped_enemy_type = None 

self. timer = -1 

self .blown_frames = 6 

def hit_test(self , bolt): 

collided = self .collidepoint(bolt. pos) 
if collided: 

self. timer = Orb. MAX_TIMER - 1 
return collided 

def update(self ): 
self. timer += 1 

if self .floating: 

self.move(0, -1, randint(1 , 2)) 
else: 

if self .move(self .direction_x, 0, 4): 
self .floating = True 

if self. timer == self .blown_frames: 
self .floating = True 

elif self. timer >= Orb. MAX_TIMER or self.y <= -40: 
game.pops. append(Pop(self. pos, 1 )) 
if self .trapped_enemy_type != None: 

game.fruits. append (Frui t (self .pos, self .trapped_enemy_type)) 
game. play_sound("pop" , 4) 

if self. timer < 9: 

self. image = "orb" + str(self. timer // 3) 
else: 

if self .trapped_enemy_type != None: 
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135 . 

136 . 

137 . 

138 . 

139 . 

140 . 
141 . 

142 . 

143 . 

144 . 

145 . 

146 . 

147 . 

148 . 

149 . 

150 . 
151 . 

152 . 

153 . 

154 . 

155 . 

156 . 

157 . 

158 . 

159 . 

160 . 
161 . 
162 . 

163 . 

164 . 

165 . 

166 . 

167 . 

168 . 

169 . 

170 . 
171 . 

172 . 

173 . 

174 . 

175 . 

176 . 

177 . 

178 . 

179 . 

180 . 
181 . 


self. image = "trap" + str(self .trapped_enemy_type) + \ 
str((self. timer // 4) % 8) 

else: 

self. image = "orb" + str(3 + (((self .timer - 9) // 8) % 4)) 

class Bolt(CollideActor) : 

SPEED = 7 

def _init_ (self, pos, dir_x): 

super() . _init_ (pos) 

self .direction_x = dir_x 
self. active = True 

def update(self ): 

if self .move(self .direction_x, 0, Bolt. SPEED): 

self. active = False 
else: 

for obj in game.orbs + [game.player]: 
if obj and obj. hit_test(self ): 
self. active = False 
break 

direction_idx = "1" if self .direction_x > 0 else "0" 

anim_frame = str((game .timer // 4) % 2) 

self. image = "bolt" + direction_idx + anim_frame 

class Pop(Actor): 

def init (self, pos, type): 

super(). _init_ ("blank", pos) 

self. type = type 
self. timer = -1 

def update(self ): 
self. timer += 1 

self. image = "pop" + str(self .type) + str(self. timer // 2) 

class GravityActor(CollideActor) : 

MAX_FALL_SPEED = 10 

def init (self, pos): 

supe r (). __init__ (pos, ANCH0R_CENTRE_B0TT0M ) 

self.vel_y = 0 
self. landed = False 
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def update(self, detect=True) : 

self.vel_y = min(self .vel_y + 1, GravityActor.MAX_FALL_SPEED) 
if detect: 

if self.move(0, sign(self .vel_y), abs(self .vel_y)): 
self.vel_y = 0 
self. landed = True 

if self. top >= HEIGHT: 
self.y = 1 

else: 

self.y += self.vel_y 

class Fruit(GravityActor) : 

APPLE = 0 
RASPBERRY = 1 
LEMON = 2 
EXTRA.HEALTH = 3 
EXTRA.LIFE = 4 

def _init_ (self, pos, trapped_enemy_type=0) : 

super()._ init_ (pos) 

if trapped_enemy_type == Robot .TYPE_NORMAL: 

self. type = choice([Fruit. APPLE, Fruit. RASPBERRY, Fruit. LEMON]) 
else: 

types = 10 * [Fruit. APPLE, Fruit. RASPBERRY, Fruit. LEMON] 
types += 9 * [Fruit. EXTRA_HEALTH] 
types += [Fruit. EXTRA_LIFE] 
self. type = choice(types) 

self .time_to_live = 500 

def update(self ): 
super() . update() 

if game.player and game.player. collidepoint(self .center): 
if self. type == Fruit. EXTRA.HEALTH: 

game.player.health = min(3, game.player.health + 1) 
game. play_sound( M bonus" ) 
elif self. type == Fruit .EXTRA_LIFE: 
game.player.lives += 1 
game. play_sound("bonus" ) 
else: 

game.player.score += (self. type + 1) * 100 
game. play_sound("score" ) 
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self .time_to_live = 0 
else: 

self .time_to_live -= 1 

if self .time_to_live <= 0: 

game.pops. append(Pop((self.x, self.y - 27), 0)) 

anim_frame = str([0, 1, 2, 1 ][(game.timer // 6) % 4]) 
self. image = "fruit" + str(self .type) + anim_frame 

class Player(GravityActor) : 

def _init_ (self): 

super(). _init_ ((0, 0)) 

self. lives = 2 
self. score = 0 

def reset(self): 

self .pos = (WIDTH / 2, 100) 

self.vel_y = 0 

self .direction_x = 1 

self .fire_timer = 0 

self .hurt_timer = 100 

self. health = 3 

self .blowing_orb = None 

def hit_test(self , other): 

if self . collidepoint(other .pos) and self .hurt_timer < 0: 
self .hurt_timer = 200 
self. health -= 1 
self.vel_y = -12 
self. landed = False 
self .direction_x = other.direction_x 
if self. health > 0: 

game.play_sound("ouch" , 4) 
else: 

game. play_sound( "die" ) 
return True 
else: 

return False 

def update(self ): 

super().update(self .health > 0) 

self .fire_timer -= 1 
self .hurt_timer -= 1 
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if self .landed: 

self .hurt_timer = min(self .hurt_timer, 100) 

if self .hurt_timer > 100: 
if self. health > 0: 

self .move(self .direction_x, 0, 4) 
else: 

if self .top >= HEIGHTS.5: 
self. lives -= 1 
self. reset() 

else: 
dx = 0 

if keyboard.left: 
dx = -1 

elif keyboard.right: 
dx = 1 

if dx != 0: 

self .direction_x = dx 

if self .fire_timer < 10: 
self .move(dx, 0, 4) 

if space_pressed() and self .fire_timer <= 0 and len(game. orbs) < 5 
x = min(730, max(70, self.x + self .direction_x * 38)) 
y = self.y - 35 

self .blowing_orb = Orb((x,y), self .direction_x) 
game.orbs. append (self .blowing_orb) 
game. play_sound(" blow" , 4) 
self .fire_timer = 20 

if keyboard.up and self.vel_y == 0 and self. landed: 
self.vel_y = -16 
self. landed = False 
game. play_sound(" jump" ) 

if keyboard.space: 

if self .blowing_orb: 

self .blowing_orb.blown_frames += 4 
if self .blowing_orb.blown_frames >= 120: 
self .blowing_orb = None 

else: 

self .blowing_orb = None 
self. image = "blank" 

if self .hurt_timer <= 0 or self .hurt_timer % 2 == 1 : 
dir_index = "1" if self .direction_x > 0 else "0" 
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if self .hurt_timer > 100: 
if self. health > 0: 

self. image = "recoil" + dir_index 
else: 

self. image = "fall" + str((game. timer // 4) % 2) 
elif self .fire_timer > 0: 

self. image = "blow" + dir_index 
elif dx == 0: 

self. image = "still" 
else: 

self. image = "run" + dir_index + str((game. timer // 8) % 4) 

class Robot(GravityActor) : 

TYPE.NORMAL = 0 

TYPE.AGGRESSIVE = 1 

def _init_ (self, pos, type): 

super() . _init_ (pos) 

self. type = type 

self. speed = randint(1 , 3) 
self .direction_x = 1 
self. alive = True 

self .change_dir_timer = 0 
self .fire_timer = 100 

def update(self ): 
super() . update() 

self .change_dir_timer -= 1 
self .fire_timer += 1 

if self .move(self .direction_x, 0, self. speed): 
self .change_dir_timer = 0 

if self .change_dir_timer <= 0: 
directions = [-1 , 1 ] 
if game.player: 

directions. append(sign(game. player.x - self.x)) 
self .direction_x = choice(directions) 
self .change_dir_timer = randint(100, 250) 

if self. type == Robot. TYPE_AGGRESSIVE and self .fire_timer >= 24: 
for orb in game.orbs: 

if orb.y >= self. top and orb.y < self. bottom and \ 
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abs(orb.x - self.x) < 200: 

self .direction_x = sign(orb.x - self.x) 

self .fire_timer = 0 

break 

if self .fire_timer >= 12: 

fire_probability = game.fire_probability() 
if game.player and self. top < game.player.bottom and \ 
self. bottom > game.player.top: 
fire_probability *= 10 
if random() < fire_probability: 
self .fire_timer = 0 
game. play_sound("laser" , 4) 

elif self .fire_timer == 8: 

game.bolts. append(Bolt((self.x + self .direction_x * 20, self.y - 38), 
self .direction_x)) 


for orb in game.orbs: 

if orb.trapped_enemy_type == None and self .collidepoint(orb. center): 
self. alive = False 
orb.floating = True 
orb.trapped_enemy_type = self. type 
game. play_sound(" trap" , 4) 
break 

direction_idx = "1" if self .direction_x > 0 else "0" 
image = "robot" + str(self .type) + direction_idx 
if self .fire_timer < 12: 

image += str(5 + (self .fire_timer // 4)) 
else: 

image += str(1 + ((game.timer // 4) % 4)) 
self. image = image 


class Game: 

def _init_ (self, player=None) : 

self. player = player 
self .level_colour = -1 
self. level = -1 

self . next_level() 

def fire_probability(self) : 

return 0.001 + (0.0001 * min(100, self. level)) 

def max_enemies(self ): 
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return min((self. level + 6) // 2, 8) 
def next_level(self ): 

self .level_colour = (self .level_colour + 1) % 4 
self. level += 1 

self. grid = LEVELS[self. level % len(LEVELS)] 
self. grid = self. grid + [self .grid[0]] 
self. timer = -1 

if self. player: 

self .player. reset () 

self. fruits = [] 
self. bolts = [] 
self. enemies = [] 
self. pops = [] 
self. orbs = [] 

num_enemies = 10 + self. level 
num_strong_enemies = 1 + int(self. level / 1.5) 
num_weak_enemies = num_enemies - num_strong_enemies 

self .pending.enemies = num_strong_enemies * [Robot .TYPE_AGGRESSIVE] + \ 
num_weak_enemies * [Robot .TYPE_NORMAL] 

shuffle(self . pending_enemies) 
self .play_sound("level" , 1) 

def get_robot_spawn_x(self ): 
r = randint(0, NUM_C0LUMNS-1 ) 

for i in range(NUM_COLUMNS) : 
grid_x = (r+i) % NUM.COLUMNS 
if self .grid[0][grid_x] : 

return GRID_BLOCK_SIZE * grid.x + LEVEL_X_OFFSET + 12 

return WIDTH/2 

def update(self ): 
self. timer += 1 

for obj in self. fruits + self. bolts + self. enemies + self. pops + \ 

[self .player] + self. orbs: 
if obj: 

obj. update () 

self. fruits = [f for f in self. fruits if f.time_to_live > 0] 
self. bolts = [b for b in self. bolts if b.active] 
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self. enemies = [e for e in self. enemies if e.alive] 

self. pops = [p for p in self. pops if p.timer < 12] 

self. orbs = [o for o in self. orbs if o.timer < 250 and o.y > -40] 

if self. timer % 100 == 0 and len(self .pending_enemies + self .enemies) > 0: 
self .fruits. append(Fruit((randint(70, 730), randint(75, 400)))) 

if self. timer % 81 == 0 and len(self .pending_enemies) > 0 and \ 
len(self .enemies) < self .max_enemies() : 
robot_type = self .pending_enemies.pop() 
pos = (self .get_robot_spawn_x(), -30) 
self .enemies. append (Robot (pos, robot_type)) 

if len(self .pending_enemies + self. fruits + self. enemies + self. pops) == 0: 
if len([orb for orb in self. orbs if orb.trapped_enemy_type != None]) == 0 

self . next_level() 

def draw(self): 

screen. blit("bg%d" % self .level_colour, (0, 0)) 

block_sprite = "block" + str(self. level % 4) 

for row_y in range(NUM_ROWS) : 
row = self .grid[row_y] 
if len(row) > 0: 

x = LEVEL_X_OFFSET 
for block in row: 
if block != : 

screen. blit(block_sprite, (x, row_y * GRID_BLOCK_SIZE)) 
x += GRID_BLOCK_SIZE 

all_objs = self. fruits + self. bolts + self. enemies + self. pops + self. orbs 
all_objs. append (self .player) 
for obj in all_objs: 
if obj: 

obj .draw() 

def play_sound(self, name, count=1): 
if self. player: 
try: 

sound = getattr(sounds, name + str(randint(0, count - 1))) 
sound. play() 
except Exception as e: 
print(e) 

CHAR.WIDTH = [27, 26, 25, 26, 25, 25, 26, 25, 12, 26, 26, 25, 33, 25, 26, 

25, 27, 26, 26, 25, 26, 26, 38, 25, 25, 25] 
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def char_width(char) : 

index = max(0, ord(char) - 65) 
return CHAR_WIDTH[ index] 

def draw_text(text , y, x=None): 
if x == None: 

x = (WIDTH - sum([char_width(c) for c in text])) // 2 
for char in text: 

screen.blit( M font0"+str(ord(char)), (x, y)) 
x += char_width(char) 

IMAGEJVIDTH = {"life" : 44, "plus" :40, "health" :40} 

def draw_status() : 

number_width = CHAR_WIDTH[0] 
s = str(game. player.score) 

draw_text(s, 451, WIDTH - 2 - (number_width * len(s))) 
draw_text("LEVEL " + str(game. level +1), 451) 

lives_health = ["life"] * min(2, game.player.lives) 
if game.player.lives > 2: 

lives_health. append ("plus" ) 
if game.player.lives >= 0: 

lives_health += ["health 1 ] * game.player.health 

x = 0 

for image in lives_health: 

screen. blit(image, (x, 450)) 
x += IMAGE_WIDTH [image] 

space_down = False 

def space_pressed() : 

global space_down 
if keyboard.space: 
if space_down: 
return False 

else: 

space_down = True 
return True 

class State(Enum): 

MENU = 1 
PLAY = 2 
GAME.OVER = 3 
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def updateQ: 

global state, game 

if state == State. MENU: 
if space_pressed() : 
state = State. PLAY 
game = Game(Player()) 
else: 

game. update() 

elif state == State. PLAY: 
if game.player.lives < 0: 
game. play_sound( "over" ) 
state = State. GAME_0VER 
else: 

game. update () 

elif state == State. GAME_0VER: 
if space_pressed() : 
state = State. MENU 
game = Game() 

def draw(): 
game. draw() 

if state == State. MENU: 

screen. blit("title" , (0, 0)) 

anim_frame = min(((game.timer + 40) % 160) // 4, 9) 
screen. blit("space" + str(anim_frame), (130, 280)) 

elif state == State. PLAY: 
draw_status() 

elif state == State. GAME_0VER: 
draw_status() 

screen. blit("over" , (0, 0)) 
pygame.mixer. quit() 

pygame.mixer. init (441 00, -16, 2, 1024) 

music. play ("theme" ) 
music. set_volume(0 .3 ) 

state = State. MENU 
game = Game() 
pgzrun.goQ 
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1 The Cavern 
title for the 
attract screen 

2 A variety of enemy 
sprite frames, 
including for them 
being trapped 

in bubbles 

3 The pop 
animation for 
when fruit 

is collected 
or expires 

4 The player sprite 
has several 
animation 
frames, including 
for running 
andjumping 
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7 The fall animation 
is shown upon 
Losing a Life 


*7 


8 Getting hit by 
enemy fire results 
in the recoil 
animation 


10 






9 Make sure to 
grab an extra life 
power-up if you 
spot one 

10 Collect fruit 
left behind by 
defeated enemies 
for extra points 
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Chapter 3 

Top-down Platformer 


Play around with the benefits 
that a different perspective 
can lend to a game 




rogger turned traditional platform games 
on their head by adopting a top-down 
perspective. It’s still fondly regarded 
more than three decades on - and 


continues to inspire programmers 
building games like modern mobile 
hit Crossy Road. The premise was simple: players guided 
frogs across a busy road and a river packed full of floating 
obstacles until they reached the safety of their home. 
Unusually, the player viewed the game as if they were 
hovering above the action. The game resembles a free-form 
maze, with players needing to plot a correct path from A to 
B to survive. Given that there are lots and lots of ways to 
die in this game, that’s easier said than done. 


Inspiration 

Frogger was ported from the arcade to Atari computers by 
John D. Harris, who worked for On-Line Systems. He 
ended up having a long association with Atari machines, for 
which he also produced Jawbreaker and Mouskattack , while 
working for On-Line Systems. He pioneered new practices 
from early in his career, not only creating a copy-protection 
system for Atari but being the first to have a continuous 
music score playing during a game. As well as working on a 
3D system for the Atari Jaguar, he has produced games for 
the PlayStation and has constantly sought to push the limits 
of design. Having been a partner in Pulsar Interactive 
Gorp and now Platoteam Inc, he is acclaimed as one of 
gaming’s legendary figures. 
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Frogger 

Released 1981 

Platforms Arcade 

Atari 8-bit 
InteLLivision 
Atari 2600 
Atari 5200 
CoLecoVision 
Commodore VIC-20 
Commodore 64 
Amstrad CPC 
ZX Spectrum 
TRS-8o/Dragon 32 
Timex Sinclair 1000 


Timex Sinclair 2068 
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The game was originally ported to just about every machine possible at the time, 
but in 1998 it also appeared late on the Sega Mega Drive, SJVES, Game Boy, and 
Game Boy Color. 


Other Notables 


Ultima / Legend of Zelda / Pokemon 


Why did the frog cross the road? To get to the other side, of course. But how did it 
cross the road? Well, that’s an entirely different question and one which many players 
of the classic arcade game Frogger often asked themselves — especially when the green 
anthropomorphic amphibian under their control got squished beneath the wheels of 
yet another lorry 

And the frog did cross that road - millions of times over. The squishing aspect 
of this iconic highway/river crossing game may sound gruesome, but it sure made for 
a rewarding challenge, ensuring that, back in 1981, Frogger was a surefire hit for maker 
Konami. The combination of pure playability and a simple premise made it perfect 
for a coin-operated machine. 

Back in the late 1970s and early 1980s, arcades flourished, leading to intense 
competition among games developers. The trick was to encourage players to insert 
as much of their (parents’) hard-earned cash as possible, and the perceived wisdom 
was that games needed to be easily explained and understood in order to get those 
initial coins moving. 

In Frogger' s case, all a player had to do was get the frog from the bottom of the 
screen to the top, dodging vehicles and crossing a hazardous river in order to scramble 
to safety. To keep players coming back for more, the developers made it difficult 
enough to ensure that failure would, at some point, be inevitable. The frustration 
resulting from not being able to get all five frogs to their various homes on the river 
bank was all that was needed to ensure the flow of cash into the arcade cabinet. 

Fledgling programmer John D. Harris was at the start of his career when 
Frogger was released. He had started working as an independent developer in March 
1981 and had cut his teeth developing versions of Starhawk , Head-on , and a Berzerk- style 
title — three games which, unfortunately, never saw the light of day. His breakthrough 
came with Jawbreaker, released that year by On-line Systems for the Atari 400 and 800 
computers. It went down a storm with reviewers and gamers. 

Even so, it attracted some controversy. Jawbreaker was the subject of an 
unsuccessful injunction from Atari due to its similarities to another arcade hit, 
Pac-Man. But it showcased John’s flair for coding and he was subsequently given the 
task of officially converting Frogger from the arcades to Atari 8-bit computers. There 
was massive demand among gamers to be able to enjoy the coin-op hits at home, and 
it become the game that defined and truly kick-started his career. 

Spawning ground 

John grew up in the United States, and had been interested in gaming and coding 
from an early age. “My first exposure to game programming happened in junior 
high,” he says. He recalls his school having an old Teletype terminal: machines like 
electromechanical typewriters which allowed typed messages to be sent from one 
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point to another. “We used it to play mainframe games like Star Trek or Colossal Cave 
Adventure ,” he continues, talking about two text-based computer games released in 
1971 and 1976, respectively “At the time, I was only vaguely aware that computers 
could do anything else.” 

Star Trek made a huge impression on him. As he watched someone playing 
the game, he noticed it was behaving differently to what he was used to seeing. “I 
asked him what was going on, and he said that he ‘changed the program’. The blank 
look on my face let him know that I had no clue what he was talking about, so 
he graciously explained further about the BASIC programming language, and he 
showed me how to ‘break’ the game execution and list the program instructions. It 
was the definitive ‘light bulb moment’ that opened up a whole new world for me.” 

In the late 1970s, more and more home computers appeared on the market. 
The Olivetti P6060 was released in April 1975 and it boasted just 8kB of RAM 
in its lowest-priced incarnation (which, incidentally, cost an eye-watering $7950). 
Meanwhile, the 8-bit Apple II was released for $1298 in June 1977. A few months 
later, Commodore released the PET, a futuristic-looking home computer based 
around the MOS Technology 6502 processor which had up to 96kB of RAM. This 
machine made a big impression on John. 

The PET was able to output monochrome graphics while software could 
be stored on cassette tape, a 5.25-inch floppy, 8-inch floppy, or a hard disk. “I really 
liked the Commodore PET and I knew a few people who had them,” John says. 
“They would let me play with them from time to time and I had been saving money 
for one. But then a friend got an Apple II and it was an interesting contrast. While 
it was missing fundamental features like full-screen editing that made working with 
the machine much more cumbersome, I could see the extra graphics potential of 
the Apple.” Still, John decided he would buy the PET and went to the store with his 
saved-up cash, excited about making his new purchase. 

“But fate stepped in and provided an alternative choice,” he recalls. “On the 
day I went into the store to buy the machine, they had just received an Atari 800. 
It didn’t take long to discover that it had all of the ease-of-use features of the PET, 
and then some, plus the colour graphics capabilities of the Apple. There was no hint 
yet of how vastly superior it really was, but this combination of features resolved a 
nagging concern within me that I was settling for lesser capabilities in the PET in 
order to get a machine that was more fun to work with. Now I could have the best 
of both worlds.” 

Even so, John had the problems that come with early adoption. “There were 
no programs for the Atari other than the BASIC and Educational System cartridges, 
and there were no tapes. Yet I bought the Atari 800 and I couldn’t have been happier 
with it.” That decision had a major influence on John’s life, leading to the porting of 
Frogger to that machine. “It’s crazy to think how much different my life would have 
been had I entered that store one day earlier and been a PET owner,” he adds. 

Creating Frogger 

In order to start porting Frogger to the Atari 400 and 800, John amassed some extra 
hardware. As well as his 48kB Atari 800, he had an Axlon RAMDISK that lent an 
extra 128kB of memory, a high-speed floppy disk interface made by LE Systems, and 
an Austin-Franklin 80-Column Board which presented an 80-column by 25-character 
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screen display on a monitor. With those in hand, he began to deconstruct the original 
game and make notes about the various aspects of its gameplay. 

Simple, distinct sections made up the playing screen. In order for the frogs to 
get from the bottom of the screen to the top, they had to cross five lanes of highway 
(which is why the game was very nearly called Highway Crossing Frog). From there, 
they had to reach the pavement on the other side and then negotiate a river. In 
each of those two sections, the frogs had to avoid busy traffic and then avoid falling 
in the water by hopping on logs while staying clear of alligators’ mouths and other 
floating hazards. 

In order to be faithful to the original, these aspects had to be retained. John 
worked on recreating the visual look of the background, producing the graphics that 
separate out the screen into the various sections, taking care to include the starting 
pavement where the frogs began their perilous journey and the five homes at the top 
of the screen which allowed them to rest safely. 

John also created the frog itself and worked on 
its movement. 

Thankfully, this was a straightforward 
task because the original designers had decided to 
go with four-way controls. “Eight-way movement 
would have offered more control, but it’s also 
more likely to move in a diagonal when it wasn’t 
intended, or vice versa,” he explains. “Often that 
would come with fatal consequences.” Indeed, 
keeping the movements simple worked well 
because it not only removed the potential margin 
for error, but allowed players to concentrate on 
the timing of the movements. 

“There’s always a balance between having enough control depth to keep the 
player interested and challenged, but not too much to where the controls become a 
downfall,” John adds. So the frogs were able to move left, right, up, and down, with 
the latter option tending only to be used when players made an error and had to 
resort to going back a step in order to avoid losing a life. At each step of the game, 
players had to keep those obstacles in mind. 

The first set of obstacles were the vehicles. The arcade version had five rows 
of traffic, each of which would move in a different direction to the adjacent ones. 
This meant the bottom row would move right-to-left, the next left-to-right and so on, 
producing a challenging game environment. If all of the vehicles headed in the same 
direction, then it might have been possible for a player to quickly make their way 
from one corner of the traffic to another. 

As it was, the game forced the brain to work with more complex movement 
patterns. In gaming, keeping a player on their toes and heightening the sense of 
danger is always a good thing. The arcade game also spiced things up by using 
different vehicles, some of which were longer or had different 
behaviours than the others. 

“There are multiple simultaneous objectives in 
creating a game world,” explains John. “It needs to be fun, 
but it should also have interesting visuals and sounds for 


I A flyer for the US 
version of the 
coin-op, released 
by Sega/Gremlin 


The arcade version 
had five rows of 
traffic, each of which 
would move in a 
different direction 
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a more complete experience. Most of the vehicle types are really only there for 
visual variety, with the play variety handled through the different regions of the 
screen. That said, a few types offer gameplay differences like faster movement or 
longer length.” 

The river section worked in much the same way, except instead of having to 
dodge through the gaps of the traffic, players needed to use the logs and the backs of 
turtles and alligators to step across. Since the gap here is water, it causes the instant 
loss of a life, and put a different spin on the second section, almost turning it into a 
level of its own. 

“The two parts are very similar, but they are a way to get both visual and subtle 
variety in play,” says John. “At their heart, both sections are still about navigating 

across scrolling safe or danger segments, with the 
water being the opposite of the roadway. So you 
hop through the gaps in the road, but avoid the 
gaps and hop onto the solid objects in the water. 
The water, however, offers additional options of 
having the turtles occasionally dive, adding an 
extra dimension to the player’s navigation and 
planning. So as you progress up the screen from 
bottom to top, the game is able to add some 
additional challenge as you’re getting closer to 
the home goals.” 

These home goals were the five safe 
places for the players’ frogs to reside. Only 
one frog was able to stay on any one lily pad, so this added some extra pressure 
and required players to employ some clever tactics. This was doubly vital because 
there was no safe banking once the frog had hopped off the final log: the frog had 
to leap straight onto an empty lily pad. Timing and positional planning at this point 
became essential. 

Collision detection 

Without solid collision detection, obstacles don’t mean much. “When a player makes 
a move, the code needs to work out where all the other objects on the screen are, 
according to their directions and speeds in relation to the character. It checks for 
collisions based on where you are: being hit by a vehicle in 
the street, landing in open water, and so on.” If there was a 
collision, then the code needed to act upon it and kill the frog, 
resulting in a fun animation to show that the character has 
died (a skull and crossbones appeared in the original). There 
were many ways to lose a life. 

A frog could be hit by a vehicle or end up in the 
water. It could collide with a snake, an otter, or the jaws of 
an alligator. It could try to use a turtle that was about to 
dive under water, taking the frog with it. It could also stay 
on a log for too long and end up going off the edge of the 
screen. When it came to trying to find a home, any frog which 
hopped into the bush by mistake, tried to take over an already 
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occupied home, or found the home had an alligator in it would also perish. All of this 
served to heighten the player’s sense of peril - hopefully without causing them to slam 
down their controller in exasperation. 

“As long as all of the mechanisms for one’s demise are reasonable and 
consistent, then we’re just increasing variety and not adding frustration,” says John. 
“Granted, you can make the case that landing in water should not be fatal to a 
frog, but that’s the rule defined by the game world - and the main point is that it’s 
consistently that way, and part of the core gameplay. Frustration sets in if the rules 
aren’t consistent or if players die from threats that aren’t readily obvious in nature.” 

There was one other way in which a frog could die. Players could run out 
of time, since each of the levels had to be completed within a time limit. In Frogger , 
this was very important because it sped up a game that might otherwise be played 
rather slowly. Forget everything you’ve learned about crossing a real-life road with 
this game: getting across fast, albeit in one piece, was everything. 

“With no time pressure, it would be too 
easy to casually wait for perfect opportunities,” 
confirms John. “You could retreat into safer 
areas until the best gaps and alignments came 
along. The timer is really the only element 
that forces the player to keep driving forwards. 

It’s what turns a stroll across the screen into a 
challenge in which the player needs to figure out 
paths in real-time while under pressure.” 

But how much time should a player 
have? “Figuring out the details of how much 
time to give is usually a matter of play-testing,” 
says John. “If you lose lives too often because 
you’re running out of time, then the timer needs to be increased. If you always have 
lots of time left, and you don’t feel pressured to complete the level in a reasonable 
amount of time, then the timer needs to be shorter. Such tests need to be performed 
by people other than the primary developers, since they are usually too familiar with 
the game and would give times skewed on the faster side.” 

With so much scope for losing a life, there also had to be a consideration over 
how many lives a player had. “Lives in games were generally picked to adjust how 
much time someone can continue to play on one quarter, back when arcades were 
the primary and intended audience for the game,” John explains. “But ultimately, it is 
good design to let players survive a few mistakes, or else it would be too frustrating. If 
the number is too high, then there isn’t enough urgency placed on survival. So three 
lives tends to be a good balance.” 

High-score table 

Frogger also spurred people on with a scoring system, with points being awarded for 
each step of progress made. A high-score table was created for bragging rights, but 
there were also bonuses to collect along the way. This encouraged replays in the 
arcade version: “Bonuses are generally ways to give players something else to strive 
for once they have conquered the basic mechanics,” says John - and bonuses also 
allowed them to gain more points for that all-important high-score table advantage. 


You can make the 
case that landing in 
water should not be 
fatal to a frog, but 
that's the rule 
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“Once you can play successfully, then the challenge is whether you can also score the 
most points.” 

Working out how such a structured game could continue to be fun and keep 
people playing was all-important. When the original developers were creating Frogger 
in the arcades, the feeling of progression meant that players would keep putting more 
money into the coin-op machines, but even in home versions there is a need to give 
players a feeling they are getting value from their purchase. 

“You always want early levels to be fairly easy for players to complete, so that 
they receive some immediate rewards and progress,” advises John. “Then, as they 
learn the mechanics and become more skilled at navigating them, the game needs to 
increase the challenge or else players will become bored.” 

He says Frogger accomplished that in two ways: “It makes the paths more 
difficult and dangerous, and it gives the player less time to make the decisions on 
how to get through them. So it both increases the challenge, along with the sense of 
urgency. More specifically, it reduces the size of the gaps between vehicles, speeds up 
some of the vehicles, and reduces the number and size of the river turtles. 

“Finally, it will replace some turtles with alligators, which are functionally just 
smaller turtles - there’s no difference between landing on an alligator’s head versus 
landing in the water - but they really do provide a more visceral threat. Having 
the greatest perceived threat also be right at the end, near the home goals, gives it 
maximum emotional impact, and maximum relief and satisfaction upon success.” 

Starting over 

Initially, development of Frogger ran reasonably smoothly and the more John got to 
grips with his Atari 800, the more he began to fall in love with it. He dedicated 
himself to gaming, enjoying Star Raider , Robotron 2084 , Shamus , and Mouskattack , and 
he almost became inseparable from his computer, taking it with him on trips so he 
could continue working. 

“In the years to come, the Atari would forever establish itself in my mind 
as one of the greatest computers ever made,” he says. “People were still discovering 
new graphic tricks and techniques ten years after the machine was introduced. If 
you compare the latest programs written for the Atari with the earliest programs, 
the huge difference between them is a testament to the magic they accomplished 
with its design.” 

But then disaster struck. His original saved Frogger code was stolen, along with 
all of his backups. “All I had left was an older backup that was near the beginning of 


The objectives 

Shortterm: Start with the background elements - this way you can get the largest amount of visual 
progress done early on. 

Medium term: Add the frog movement, player controls, and collision detection - enough for a basic 
playable game. 

Long term: Throw in the remaining elements like snakes, alligators, bonus items, and a timer. Here is 
also where the game should be tested for balance, excitement, and frustration. 
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stage 3,” he says. “I had the basic gameplay, but all the additional elements, and all 
the balancing, were gone.” It meant John ended up writing Frogger not once but twice, 
and he says the second time didn’t feel as good as the first. 

“I kept trying to remember and recreate what I had already done, mixed with 
the emotions of the loss,” John continues. “If I could have separated myself from all 
that, and just re-solved the issues rather than reconstruct earlier solutions, I probably 
could have saved myself a lot of time and grief.” Fortunately, though, the version he 
created sparkled, and it communicated the very essence of what made Frogger a major 
hit. Sales were helped by the game’s long-lived popularity in the arcades. Indeed, the 
game — along with Joust, Millipede , Super Pac-Man, and Donkey Kong Jr — was used in the 
first video game world championships held in January 1983. The highest-ever score 
for the arcade game is 970,440 points, achieved in 2012, which shows the game’s 
enduring popularity. 

Frogger wasn’t the end of the road for the green hero, though. It gained a 
number of follow-ups including Frogger II: ThreeeDeep!, which introduced three 
consecutive screens, while Ribbit! allowed the frogs to gobble wasps, flies, and crabs. 
Frogger 2 on the Game Boy Color allowed players to control Frogger’s girlfriend Lily. 
“It’s the only genre I can think of where you have so many options, and so much 
control,” says John. “The creative limits are boundless and it’s an excellent mix 
between creative energies and technical challenges. I wish you all the best if you 
choose to follow this path.” 

But how does John view the earliest days of the indi 
still set to leap on to the masses? “The most interesting detail 
about the early computer scene, and also one of the things 
I miss the most, is that everyone was very open about their 
efforts, and each new discovery was enthusiastically shared,” 

John says. “It was an era of experimentation, and the first 
thing we’d do after finding something new was tell everyone 
else about it. This was only partially due to the desire to ‘look 
cool’ for figuring it out. There was also a genuine desire for 
others to benefit from it, because the more people we had 
using the best techniques, the better programs we would get 
at every level.” 


/, when Frogger was 
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TV screen 


Learn from the master 

John D. Harris has constantly looked to improve his design skills, learning new techniques as he’s 
moved from one platform to another. 

Difficulty level: You always want early levels to be fairly easy for players to complete, so that they 
receive some immediate rewards and progress. 

Easy controls: The simpler the control scheme is, the more intuitive your game will be to play and the 
less potential there will be for input mistakes or confusion. 
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I nfinite Burner is our take on the classic Frogger 
gameplay. The original game takes place 
on a single screen, with a busy road at the 
bottom and a river at the top. In our game, 
the level is procedurally generated and scrolls 
continuously The player must progress fast 
enough to avoid falling off the bottom of the screen - if 
this happens, an Eagle flies down the screen and catches 
the player, resulting in Game Over. 

The level is divided into a series of sections, each 
of a particular type — Grass, Dirt, Road, Pavement, Rail, or 
Water. Each section is made up of a series of rows, where 
each row corresponds to one sprite from the images folder. 
Rows are 40 pixels high, although you may notice that 
some of the sprites are 60 pixels high; this is just a visual 
effect — the sprite overhangs the row above, but the row is 
still considered 40 pixels high for gameplay purposes. 


Download the code 

Download the fully commented Infinite Bunner game code, along 
with all the graphics and sounds, from wfmag.cc/CTCl-bunner 
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Road, Water, and Rail 
sections all feature moving objects: 
Cars, Logs, and trains (the latter has 
no class of its own). Grass sections 
may contain Hedges, which the 
player must walk around. Because 
these objects always stay within 
their rows, we classify them as child 
objects of the rows. Child objects 
are drawn relative to their parent 
rows — e.g. if a road row has a Y 
coordinate of 200, and a car on the 
road has a Y coordinate of 10, the 
car would be drawn at Y coordinate 
210. To provide this functionality, 
all objects in the game inherit from 
a class called MyActor, which in turn 
inherits from Pygame Zero’s built-in 
Actor class. MyActor works just like 
Actor except that it overrides the 
update and draw methods in order 
to update and draw the list of child 
objects. It also ensures objects are 
drawn at the correct position on screen, taking the scrolling of the level into account. 

All rows inherit from the Row class. This performs several important tasks, 
such as collision detection. Some of the methods provide default results, which can be 
overridden in inherited classes. For example, the push method - called by the player 
to determine movement on the x-axis — returns zero, resulting in no movement. In the 
Water class, however, this method is overridden, 
and causes the player to move on the x-axis if 
they’re currently sitting on a log. 

The ActiveRow class inherits from Row, 
and is the base class for Water and Road. What 
those two classes have in common is that they 
both feature moving objects (logs and cars) 
which start just off-screen and move horizontally. 

ActiveRow deals with creating and destroying 
these child objects. The two subclasses override 
a number of methods - one key example being 
check_collision. The Bunner. update method calls this to find out if the player has 
collided with something, and if so, what to do about it. In the case of Road, colliding 
with a car kills the player and replaces the player sprite with the ‘splat’ image. For 
Water, however, colliding with a log is a good thing, whereas not colliding with a log 
ends the game and replaces the player sprite with the ‘splash’ animation. 

The Game class maintains a reference to the player object, and is also 
responsible for creating, updating, and deleting rows. The final part of the code uses 
a simple state machine system to update and draw the game objects. 


Colliding with a car kills 
the player and replaces 
the player sprite with 
the ‘splat’ image 


Challenges 


■ ActiveRow. update ensures a minimum 
distance of 240 pixels between the start of 
one child object and the start of the next - or 
half that for rows where child objects have a 
speed of 2. A random factor varies the distance 
between each child object.These rules apply 
to both Road and Water rows - but how would 
you make it so that each of those row types 
could have its own custom values or rules for 
the spacing of child objects? 


■ Try adding a new type of row to the game 
- perhaps lava, ice, or space? The graphics 
could initially be a copy and recolouring of an 
existing row type’s. More importantly,you’ll 
need to think about whether the new row will 
be a variation on an existing one,or have a 
completely new gameplay mechanic. 
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Rows after rows after rows 

The_ init _(constructor) method 

of the Game class creates a list to 
contain the rows.To begin with, this just 
contains a single Grass row.This will 
be the first row, and will appear at the 
bottom of the screen - but how does 
the game decide which types of rows 
to create after that? Each row class - 
Grass, Road, Di rt, Rail, Pavement, 
and water - has a next method, which 
decides what the next row will be. Each 
method makes a decision based on the 
current row’s index - in other words, 
the number of the row’s sprite. 

There are 16 grass and dirt sprites, 
four rail sprites,six road sprites,three pavement sprites,and eight water sprites.These sprites only 
tile together correctly in certain combinations - for example, Grass 6 must be followed by Grass 7. 

So some of the rules in the next methods ensure that such rows occur in the correct sequence. Other 
rules make random choices as to which row comes next. For example, a sequence of Grass or Di rt 
rows is followed by either Road or water. 

Random probabilities of rows can also be used to determine how many rows of certain types 
occur in sequence. In the case of water rows, there are always at least two in sequence, but after 
the second one there’s always a 50-50 chance of another, up to a maximum of seven.The use of 
randomness ensures that the level is different each time you play. 



Solving the Hedge-mash 

Grass rows sometimes contain Hedges.These block certain parts of the row, requiring the 
player to make a detour around them.The function generate_hedge_mask decides the layout 
of hedge segments in a row. A mask is a series of Boolean values which allow or prevent parts 
of an underlying image from showing through. This function creates a mask representing 
the presence or absence of hedges in a Grass row. False means a hedge is present; True 
represents a gap. 

Initially we create a list of twelve elements. 

For each element there is a small chance of a gap, 
but often all elements will be False, representing 
a hedge with no gaps. We then randomly set 
one element to True, to ensure that there is 
always at least one gap that the player can get 
through. Single-tile gaps aren’t wide enough for 
the player to fit through, so the next step is to 
widen any gaps to a minimum of three tiles. Once 
the mask has been generated, the function 
ciassify_hedge_segment is used to determine 
which sprite to use for each hedge segment. 
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How to run the game 

Open the bunner.py file in a Python editor,such as IDLE,and select Run > Run Module. 
For more details, see the ‘Setting up’section on page 186. 


Download the code wfmag.ee/cri 


001. import pgzero, pgzrun, pygame, sys 
002. from random import * 

003. from enum import Enum 

004. 

005. if sys.version_info < (3,5): 

006. print("This game requires at least version 3.5 of Python. Please download" 

007. "it from www.python.org") 

008. sys.exit() 

009. 

010. pgzero_version = [int(s) if s.isnumeric() else s 

011. for s in pgzero._version_.split('.’)] 

012. if pgzero_version < [1,2]: 

013. print("This game requires at least version 1.2 of Pygame Zero. You are" 

014. "using version {pgzero._version_}. Please upgrade using the command" 

015. "'pip install —upgrade pgzero'") 

016. sys.exit() 

017. 

018. WIDTH = 480 

019. HEIGHT = 800 

020. TITLE = "Infinite Bunner" 

021 . 

022. ROW.HEIGHT = 40 

023. DEBUG_SHOW_ROW_BOUNDARIES = False 

024. 

025. class MyActor(Actor) : 

026. def init (self, image, pos, anchor=("center" , "bottom")): 

027. super(). _init_ (image, pos, anchor) 

028. self .children = [] 

029. 

030. def draw(self, offset.x, offset_y): 

031. self.x += offset_x 

032. self.y += offset_y 

033. 

034. super().draw() 

035. for child_obj in self .children: 

036. child_obj.draw(self.x, self.y) 

037. 

038. self.x -= offset_x 

039. self.y -= offset_y 
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040 . 
041 . 
042 . 
043 . 
044 . 
045 . 
046 . 
047 . 
048 . 
049 . 
050 . 
051 . 
052 . 
053 . 
054 . 
055 . 
056 . 
057 . 


def update(self ): 
self.y += 12 


class Eagle(MyActor) : 


class PlayerState(Enum) : 


def update(self): 

for child_obj in self .children: 
child_obj .updateQ 


def _init_ (self, pos): 

super(). _init_ ("eagles", pos) 

self .children. append(MyActor("eagle" , (0, -32))) 


ALIVE = 0, 
SPLAT = 1 , 
SPLASH = 2, 
EAGLE = 3 


058 . 

059 . DIRECTIONJJP = 0 

060 . DIRECTION.RIGHT = 1 

061 . DIRECTION.DOWN = 2 

062 . DIRECTION.LEFT = 3 

063 . 

064 . direction_keys = [keys.UP, keys.RIGHT, keys.DOWN, keys.LEFT] 
065 . 

066 . DX = [0,4,0,-4] 

067 . DY = [-4,0,4,0] 

068 . 

069 . class Bunner(MyActor) : 

070 . MOVE.DISTANCE = 10 


071 . 
072 . 
073 . 
074 . 
075 . 
076 . 
077 . 
078 . 
079 . 
080 . 
081 . 
082 . 
083 . 
084 . 
085 . 
086 . 


def _init_ (self, pos): 

super(). _init_ ("blank", pos) 

self. state = PlayerState.ALIVE 

self .direction = 2 

self. timer = 0 

self .input_queue = [] 

self.min_y = self.y 


def handle_input(self , dir): 


for row in game.rows: 


if row.y == self.y + Bunner .M0VE_DISTANCE * DY[di ]: 


if row.allow_movement (self .x + Bunner.MOVE_DISTANCE * DX[dir]): 
self .direction = dir 
self. timer = Bunner.MOVE_DISTANCE 
game.play_sound(" jump" , 1) 
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087 . 
088 . 
089 . 
090 . 
091 . 
092 . 
093 . 
094 . 
095 . 
096 . 
097 . 
098 . 
099 . 
100 . 
101 . 
102 . 

103 . 

104 . 

105 . 

106 . 

107 . 

108 . 

109 . 

110 . 
Ill . 
112 . 

113 . 

114 . 

115 . 

116 . 

117 . 

118 . 

119 . 

120 . 
121 . 
122 . 

123 . 

124 . 

125 . 

126 . 

127 . 

128 . 

129 . 

130 . 
131 . 

132 . 

133 . 


return 

def update(self ): 

for direction in range(4): 

if key_just_pressed(direction_keys[direction]) : 
self .input_queue. append (direction) 

if self. state == PlayerState.ALIVE: 

if self. timer == 0 and len(self .input_queue) > 0: 
self .handle_input (self . input_queue.pop(0)) 

land = False 

if self. timer > 0: 

self.x += DXEself .direction] 
self.y += DYEself .direction] 
self. timer -= 1 
land = self. timer == 0 

current_row = None 
for row in game.rows: 
if row.y == self.y: 
current_row = row 
break 

if current_row: 

self. state, dead_obj_y_offset = current_row.check_collision(self .x) 

if self. state == PlayerState. ALIVE: 
self.x += current_row. push() 

if land: 

current_row. play_sound() 

else: 

if self. state == PlayerState. SPLAT: 

current_row.children. insert(0, MyActor("splat" + \ 

str(self .direction), (self.x, dead_obj_y_offset))) 
self. timer = 100 

else: 

if self.y > game.scroll_pos + HEIGHT + 80: 

game.eagle = Eagle((self .x, game.scroll_pos)) 

self. state = PlayerState.EAGLE 

self. timer = 150 

game.play_sound( "eagle" ) 

self.x = max(16, min(WIDTH - 16, self.x)) 
else: 

self. timer -= 1 
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134. 

135. self.min_y = min(self .min_y, self.y) 

136. self. image = "blank" 

137. 

138. if self. state == PlayerState. ALIVE: 

139. if self. timer > 0: 

140. self. image = "jump" + str(self .direction) 

141. else: 

142. self. image = "sit" + str(self .direction) 

143. elif self. state == PlayerState.SPLASH and self. timer > 84: 

144. self. image = "splash" + str(int((100 - self. timer) / 2)) 

145. 

146. class Mover(MyActor) : 

147. def _init_ (self, dx, image, pos): 

148. super(). _init_ (image, pos) 

149. self.dx = dx 

150. 

151. def update(self ): 

152. self.x += self.dx 

153. 

154. class Car(Mover): 

155. SOUND.ZOOM = 0 

156. SOUND.HONK = 1 

157. 

158. def _init_ (self, dx, pos): 

159. image = "car" + str(randint(0, 3)) + ("0" if dx < 0 else "1") 

160. super(). _init_ (dx, image, pos) 

161. self. played = [False, False] 

162. self. sounds = [("zoom", 6), ("honk", 4)] 

163. 

164. def play_sound(self , num): 

165. if not self .played[num]: 

166. game. play_sound(*self .sounds[num]) 

167. self .played[num] = True 

168. 

169. class Log(Mover): 

170. def init_ (self, dx, pos): 

171. image = "log" + str(randint(0, 1)) 

172. super(). _init_ (dx, image, pos) 

173. 

174. ; class Train(Mover) : 

175. def init_ (self, dx, pos): 

176. image = "train" +str(randint(0, 2)) + ("0" if dx < 0 else "1") 

177. super(). _init_ (dx, image, pos) 

178. 

179. class Row(MyActor) : 

180. def init_ (self, base_image, index, y): 
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222 . 

223. 

224. 

225. 

226. 
227. 


super(). _init_. (base_image + str(index), (0, y), ("left", "bottom")) 
self. index = index 
self.dx = 0 

def next(self): 
return 

def collide(self , x, margin=0): 
for child_obj in self .children: 

if x >= child_obj.x - (child_obj.width / 2) - margin \ 

and x < child_obj.x + (child_obj.width / 2) + margin: 
return child_obj 

return None 

def push(self): 
return 0 

def check_collision(self , x): 
return PlayerState.ALIVE, 0 

def allow_movement(self , x): 

return x >= 16 and x <= WIDTH-16 

class ActiveRow(Row) : 

def _init_ (self, child_type, dxs, base_image, index, y): 

super(). _init_. (base_image, index, y) 
self .child_type = child_type 
self. timer = 0 
self.dx = choice(dxs) 

x = -WIDTH / 2 - 70 
while x < WIDTH / 2 + 70: 
x += randint(240, 480) 

pos = (WIDTH / 2 + (x if self.dx > 0 else -x), 0) 
self .children. append (self . child_type(self .dx, pos)) 

def update(self ): 
super().update() 

self .children = [c for c in self .children if c.x > -70 and c.x < WIDTH + 70] 
self. timer -= 1 

if self. timer < 0: 

pos = (WIDTH + 70 if self.dx < 0 else -70, 0) 

self .children. append(self.child_type(self.dx, pos)) 

self. timer = (1.0 + randomQ) * (240.0 / abs(self.dx)) 
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269. 
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272. 

273. 

274. 


class Hedge(MyActor) : 

def _init. (self, x, y, pos): 

super()._ init__ ("bush"+str(x)+str(y), pos) 

def generate_hedge_mask() : 

mask = [random() < 0.01 for i in range(12)] 
mask[randint(0, 11)] = True 

mask = [sum(mask[max(0, i-1):min(12, i+2)]) > 0 for i in range(12)] 

return [mask[0]] + mask + 2 * [mask[-1]] 

def classify_hedge_segment(mask, previous_mid_segment) : 
if mask[1]: 

sprite_x = None 
else: 

sprite_x = 3 - 2 * mask[0] - mask[2] 
if sprite_x == 3: 

if previous_mid_segment == 4 and mask[3]: 

return 5, None 
else: 

if previous_mid_segment == None or previous_mid_segment == 4: 
sprite_x = 3 

elif previous_mid_segment == 3: 
sprite_x = 4 

return sprite_x, sprite_x 

else: 

return sprite_x, None 
class Grass(Row): 

def _init. (self, predecessor, index, y): 

super()._ init_ ("grass" , index, y) 

self .hedge_row_index = None 
self .hedge_mask = None 

if not isinstance(predecessor, Grass) or predecessor.hedge_row_index == None: 
if random() < 0.5 and index > 7 and index < 14: 
self .hedge_mask = generate_hedge_mask() 
self .hedge_row_index = 0 
elif predecessor.hedge_row_index == 0: 

self .hedge_mask = predecessor.hedge_mask 
self .hedge_row_index = 1 

if self .hedge_row_index != None: 
previous_mid_segment = None 
for i in range(1 , 13): 

sprite_x, previous_mid_segment = \ 
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classify_hedge_segment(self .hedge_mask[i - 1 :i + 3], 
previous_mid_segment) 
if sprite_x != None: 

self .chiIdren. append (Hedge (sprite_x, self .hedge.row_index, 
(i * 40 - 20, 0))) 

def allow_movement(self , x): 

return super() . allow_movement(x) and not self . collide(x, 8) 

def play_sound(self ): 

game.play_sound("grass" , 1) 

def next(self): 

if self .index <= 5: 

row.class, index = Grass, self. index + 8 
elif self. index == 6: 

row.class, index = Grass, 7 
elif self. index == 7: 

row.class, index = Grass, 15 
elif self. index >= 8 and self. index <= 14: 

row.class, index = Grass, self. index + 1 
else: 

row.class, index = choice((Road, Water)), 0 
return row_class(self , index, self.y - ROW.HEIGHT) 
class Dirt(Row): 

def _init_ (self, predecessor, index, y): 

super()._ init_ ("dirt" , index, y) 

def play_sound(self): 

game.play_sound("dirt" , 1) 

def next(self): 

if self .index <= 5: 

row.class, index = Dirt, self. index + 8 
elif self. index == 6: 

row.class, index = Dirt, 7 
elif self. index == 7: 

row.class, index = Dirt, 15 
elif self. index >= 8 and self. index <= 14: 

row.class, index = Dirt, self. index + 1 
else: 

row.class, index = choice((Road, Water)), 0 
return row_class(self , index, self.y - ROW.HEIGHT) 
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367. 

368. 


class Water(ActiveRow): 

def _init. (self, predecessor, index, y): 

dxs = [-2,-1 ]*(predecessor.dx >= 0) + [1,2]*(predecessor.dx <= 0) 
super()._ init_ (Log, dxs, "water", index, y) 

def update(self ): 
super().update() 

for log in self .children: 

if game.bunner and self.y == game.bunner.y \ 

and log == self .collide(game.bunner.x, -4): 
log.y = 2 
else: 

log.y = 0 

def push(self): 
return self.dx 

def check_collision(self , x): 
if self . collide(x, -4): 

return PlayerState.ALIVE, 0 
else: 

game. play_sound ( "splash" ) 
return PlayerState.SPLASH, 0 

def play_sound(self) : 

game. play_sound(" log" , 1) 

def next(self): 

if self. index == 7 or (self. index >= 1 and random() < 0.5): 

row_class, index = Dirt, randint(4,6) 
else: 

row_class, index = Water, self. index + 1 

return row_class(self , index, self.y - ROWJHEIGHT) 

class Road(ActiveRow) : 

def _init. (self, predecessor, index, y): 

dxs = list(set(range(-5, 6)) - set([0, predecessor.dx])) 
super()._ init_ (Car, dxs, "road", index, y) 

def update(self ): 
super().update() 

for y.offset, car_sound_num in [(-ROW.HEIGHT, Car.SOUND.ZOOM), 

(0, Car.SOUND.HONK), (ROW.HEIGHT, Car.SOUND.ZOOM)]: 
if game.bunner and game.bunner.y == self.y + y_offset: 
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for chilcLobj in self .children: 
if isinstance(child_obj , Car): 

dx = child_obj.x - game.bunner.x 

if abs(dx) < 100 and ((child_obj.dx < 0) != (dx < 0)) \ 
and (y_offset == 0 or abs(child_obj.dx) >1): 
child_obj. play_sound(car_sound_num) 

def check_collision(self , x): 
if self .collide(x) : 

game.play_sound("splat" , 1) 
return PlayerState.SPLAT, 0 
else: 

return PlayerState.ALIVE, 0 

def play_sound(self): 

game. play_sound(" road" , 1) 


def next(self): 

if self. index == 0: 

row_class, index = Road, 1 
elif self. index < 5: 
r = random() 
if r < 0.8: 

row_class, index = Road, self. index + 1 
elif r < 0.88: 

row_class, index = Grass, randint(0,6) 
elif r < 0.94: 

row_class, index = Rail, 0 
else: 

row_class, index = Pavement, 0 


else: 

r = random() 
if r < 0.6: 

row_class, index = Grass, randint(0,6) 
elif r < 0.9: 

row_class, index = Rail, 0 
else: 

row_class, index = Pavement, 0 


return row_class(self , index, self.y - ROW_HEIGHT) 


class Pavement(Row) : 

def _init. (self, predecessor, index, y): 

super(). _init_ ("side", index, y) 

def play_sound(self ): 

game. play_sound( "sidewalk" , 1) 
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416. 

417. def next(self): 

418. if self .index < 2: 

419. row_class, index = Pavement, self. index + 1 

420. else: 

421. row_class, index = Road, 0 

422. 

423. return row_class(self , index, self.y - ROW_HEIGHT) 

424. 

425. ; class Rail(Row): 

426. def init (self, predecessor, index, y): 

427. super(). _init_ ("rail", index, y) 

428. self .predecessor = predecessor 

429. 

430. def update(self): 

431. super() .update() 

432. 

433. if self. index == 1: 

434. self .children = [c for c in self .children if c.x > -1000 

435. and c.x < WIDTH + 1000] 

436. 

437. if self.y < game.scroll_pos+HEIGHT and len(self. children) == 0 \ 

438. and random() < 0.01: 

439. dx = choice([-20, 20]) 

440. self .children. append(Train(dx, (WIDTH + 1000 if dx < 0 else -1000, -13))) 

441. game. play_sound(" bell") 

442. game.play_sound("train" , 2) 

443. 

444. def check_collision(self , x): 

445. if self. index == 2 and self .predecessor. collide(x) : 

446. game.play_sound("splat" , 1) 

447. return PlayerState.SPLAT, 8 

448. else: 

449. return PlayerState.ALIVE, 0 

450. 

451. def play_sound(self ): 

452. game.play_sound("grass" , 1) 

453. 

454. def next(self): 

455. if self. index < 3: 

456. row_class, index = Rail, self. index + 1 

457. else: 

458. item = choice( ((Road, 0), (Water, 0)) ) 

459. row_class, index = item[0], item[1] 

460. 

461. return row_class(self , index, self.y - ROWJHEIGHT) 

462. 
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508. 

509. 


class Game: 

def _init_ (self, bunner=None) : 

self. bunner = bunner 
self .looped_sounds = {} 

try: 

if bunner: 

music. set_volume(0 . 4) 
else: 

music. play ("theme" ) 
music. set_volume(1 ) 
except: 
pass 

self. eagle = None 
self. frame = 0 

self. rows = [Grass(None, 0, 0)] 
self .scroll_pos = -HEIGHT 

def update(self ): 
if self. bunner: 

self .scroll_pos -= max(1 , min(3, float(self .scroll_pos + HEIGHT 
- self .bunner.y) / (HEIGHT // 4))) 

else: 

self .scroll_pos -= 1 

self. rows = [row for row in self. rows if row.y < int(self .scroll_pos) 

+ HEIGHT + ROW.HEIGHT * 2] 

while self .rows[-1].y > int(self .scroll_pos)+ROW_HEIGHT: 
new_row = self .rows[-1]. next() 
self .rows. append(new_row) 

for obj in self. rows + [self .bunner, self. eagle]: 
if obj: 

obj. update() 

if self. bunner: 

for name, count, row_class in [("river", 2, Water), ("traffic", 3, Road)] 
volume = sum([16.0 / max(16.0, abs(r.y - self .bunner.y)) for r in 
self. rows if isinstance(r, row_class)]) - 0.2 
volume = min(0.4, volume) 
self . loop_sound(name, count, volume) 

return self 

def draw(self): 
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all_objs = list(self .rows) 

if self.bunner: 

all_objs. append (self .bunner) 

def sort_key(obj) : 

return (obj.y + 39) // ROW.HEIGHT 

all_objs.sort(key=sort_key) 
all_objs. append (self .eagle) 

for obj in all_objs: 
if obj: 

obj .draw(0, -int(self .scroll_pos)) 

if DEBUG_SHOW_ROW_BOUNDARIES: 
for obj in all_objs: 

if obj and isinstance(obj , Row): 

pygame.draw. rect(screen. surface, (255, 255, 255), 

pygame.Rect(obj .x, obj.y - int(self .scroll_pos), 
screen.surface. get_width(), ROW_HEIGHT), 1) 
screen.draw. text(str(obj .index), (obj.x, obj.y 
- int(self .scroll_pos) - ROW_HEIGHT)) 


def score(self): 

return int(-320 - game.bunner.min_y) // 40 

def play_sound(self , name, count=1): 
if self.bunner: 

sound = getattr(sounds, name + str(randint(0, count - 1))) 
sound. play() 

def loop_sound(self , name, count, volume): 

if volume > 0 and not name in self .looped_sounds: 
full_name = name + str(randint(0, count - 1)) 
sound = getattr(sounds, full_name) 
sound. play (-1 ) 

self .looped_sounds[name] = sound 

if name in self .looped_sounds: 

sound = self .looped_sounds[name] 
if volume > 0: 

sound. set_volume(volume) 
else: 

sound. stop() 

del self .looped_sounds[name] 
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def stop_looped_sounds(self ): 

for sound in self .looped_sounds. values() : 
sound. stop() 

self .looped_sounds. clear() 

key_status = {} 

def key_just_pressed(key) : 
result = False 

prev_status = key_status.get(key, False) 

if not prev_status and keyboard[key]: 
result = True 

key_status[key] = keyboard[key] 
return result 

def display_number(n, colour, x, align): 
n = str(n) 

for i in range(len(n)) : 

screen. blit("digit" + str(colour) + n[i], (x + (i - len(n) * align) * 25, 0)) 

class State(Enum): 

MENU = 1 , 

PLAY = 2, 

GAME.OVER = 3 

def update(): 

global state, game, high_score 

if state == State.MENU: 

if key_just_pressed(keys. SPACE): 
state = State. PLAY 
game = Game(Bunner((240, -320))) 
else: 

game.update() 
elif state == State. PLAY: 

if game.bunner.state != PlayerState.ALIVE and game.bunner.timer < 0: 
high_score = max(high_score, game. score()) 

try: 

with open("high. txt" , "w") as file: 
f ile.write(str(high_score)) 
except: 
pass 
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604. 

605. state = State.GAME.OVER 

606. else: 

607. game. update () 

608. 

609. elif state == State.GAME_0VER: 

610. if key_just_pressed(keys. SPACE): 

611. game. stop_looped_sounds () 

612. state = State.MENU 

613. game = Game() 

614. 

615. def draw(): 

616. game.draw() 

617. 

618. if state == State.MENU: 

619. screen. blit("title" , (0, 0)) 

620. screen. blit("start" + str([0, 1, 2, 1 ][game.scroll_pos // 6 % 4]), 

621. ((WIDTH - 270) // 2, HEIGHT - 240)) 

622. elif state == State.PLAY: 

623. display_number(game.score(), 0, 0, 0) 

624. display_number(high_score, 1, WIDTH - 10, 1) 

625. 

626. elif state == State.GAME.OVER: 

627. screen. blit("gameover" , (0, 0)) 

628. 

629. try: 

630. pygame.mixer. quit() 

631. pygame.mixer. init(441 00, -16, 2, 512) 

632. pygame.mixer. set_num_channels(1 6) 

633. except: 

634. pass 

635. 

636. try: 

637. with open("high. txt" , "r") as f: 

638. high_score = int(f . read()) 

639. except: 

640. high_score = 0 

641 . 

642. state = State.MENU 

643. game = Game() 

644. 

645. pgzrun.goQ 
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1 Trains hurtle 
along the 
rail tracks 

2 Get scrolled off 
the bottom of the 
screen and an 
eagle will swoop 
down for the kill 



3 The digits used to 
show the current 
and high scores 

4 Hedge must be 
constructed so 
there's a gap to 
pass through 


3 




5 Frames of the 
animation for 
falling into 
the water 

6 Movement and 
splat animation 
frames for 

our bunny 



5 








6 
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flattened bunny 

8 The scrolling 
backdrop is 
contructed from 
horizontal rows 
such as dirt, grass, 
and rail tracks 

9 Various-coloured 
cars move right 
and left along 
the roads 

10 Logs enable the 
bunny to safely 
traverse rivers 
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Chapter 4 

Fixed Shooter 


Some shooters confine the 
gameplay to a single screen while 
limiting the player’s movement. 
Restrictions can build challenge 
and difficulty, making for truly 
addictive gaming 




fixed shooter is one style of shoot-’em- 
up game, restricting a player's character 
to a particular axis or a small section of 
a single screen. Many early titles made 
use of this gaming mechanic, from Space 
Invaders to Galaxian, and one of the most 


popular was Centipede , published by Atari in 1980. One of 
the first twitch games, the original arcade version made use 
of a mini-trackball as a controller, requiring lightning-fast 
reactions to prevent a long centipede from reaching the 
bottom of the screen. As well as shooting the centipede 
itself, players had to blast the fungi in its path to slow it down 
— munching on a mushroom would cause the centipede to 
fall to the next row. Accidentally hitting the centipede in 
the middle would cause it to split into two pieces, doubling 
the danger. Added insect enemies increased the tension 
and pace. 


Inspiration 

Centipede was developed for Atari by Dona Bailey and her 
superviser Ed Logg. Dona started her career working for 
General Motors, programming displays and cruise-control 
systems, but she became interested in games after playing 
the likes of Space Invaders and decided to join Atari’s coin-op 
division. After being assigned the role of software engineer 
and creating Centipede , in 1982 she moved to Videa, which 
had been founded by several ex-Atari employees, and 
continued to write games. Meanwhile Ed - who had also 
produced Asteroids - went on to create Millipede , Xybots , 
Gauntlet , and many more early gaming classics throughout 
the 1980s. 
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Platforms Arcade 

Atari 2600 
Atari 5200 


Atari 7800 
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Other versions of Centipede were created by Atarisoft for home computers including the 
Apple II and Commodore 64, and it also appeared on the Sega Mega Drive, Game Gear, 
and Master System among others. 

Other Notables Space Invaders / Galaxian / Galaxy Wars 


Where do you start if you’ve never written a computer game before. Does lack of 
experience matter? Go back to the 1980s and you’ll find scores of coders in exactly 
the same boat. It certainly didn’t stop them from coming up with amazing ideas 
that would define gaming for years and decades to come: often, jumping feet-first 
into something is the best way to get started. 

For many software engineers, Dona 
Bailey is an inspiration. Before 1980, she hadn’t 
even played a video game. That year, she 
played her first game — Space Invaders — and she 
immediately realised that she’d found something 
special. It inspired her so much that she decided 
to leave her job as a 6502 assembly language 
programmer for General Motors in California, 
where she was coding sensors for the first 
Cadillac to carry an on-board microprocessor. 

Dona saw that Atari was building video 
game arcade cabinets in Sunnyvale, California, 
and she applied for a job. The games developer 
took her on in June 1980, where she began a steep learning process, discovering 
the different programming approaches needed to create a game, and coming to 
understand concepts of what was fun and why. 

“I had to learn what seemed like thousands of details in order to begin 
working on a game,” Dona says. “At General Motors I had worked with teams of 
programmers who coded from well-defined specifications, and each person created 
limited segments of the total program. It was completely different at Atari, where 
each programmer was expected to code an entire game.” 

Devising ideas 

Atari encouraged programmers to come up with ideas for games. It would hold 
mammoth brainstorming sessions, which prompted coders to open their minds, 
explore what worked and what didn’t, and discuss the intricacies of design. 
An idea for the game that would become Centipede had already been jotted in a 
notebook by the time Dona arrived. “It was one sentence: 

A multi-segmented insect crawls onto the screen and is 
shot by the player,’ ” she recalls. She chose it as a game she 
wanted to develop. 

The learning process started in earnest. “Before 
I could begin, I needed to be taught how to create the 
graphics for the game hardware, how to use the major and 


1 The attract 
screen for the 
1980 coin-op has 
the centipede 
moving down the 
side of the high 
score table 


I had to learn 
what seemed like 
thousands of details 
in order to begin 
working on a game 
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minor interrupts for the 6502 microprocessor, how to set up the data structures for 
the motion objects in the game, how to use Atari’s custom game controllers and 
custom sound chip - it went on and on,” she says. “It was a really intense learning 
curve for me for at least six months when I started at Atari.” 

Dona says that she started at Atari with no real clue about what she wanted 
to do there. But that was very much a positive thing. Although having a solid 
structure in place for your game will save you lots of time, allow you to see the 
overall picture of a game, and understand how certain parts of it will affect other 
areas, many programmers like Dona jumped straight into coding and developed 
the game on-the-fly. 

As we’ll see later, this can work very well. As long as you understand any 
system constraints - Centipede was to be produced as a coin-operated arcade game, 
so Dona was assigned an extremely stable raster graphics board which displayed 16 
motion objects on the screen at one time - a free-style approach enables the coder 
to visualise the game as she sees fit. 

Looks and movement 

Dona’s first task was to work on the look of the centipede itself. “Based on the brief 
game description from the notebook, it just made sense to use as many motion objects 
as possible for segments of the centipede,” she reveals. “I visualised the centipede 
as a string of connected ‘pop beads’ and I remember that I looked forward to the 
gliding motion I would create as the centipede turned when it encountered the 
edges of the screen. I was thinking much more about how it looked versus planning 
gameplay or pacing, especially in the early days of programming the game.” 

Once she had the right graphical look, it was time to work on the game 
itself, starting with the movement of the main character. “In the game, the multi- 
segmented centipede crawls along the screen at the top, travels to the other side of 
the screen, turns down the screen, and crawls back to the other side of the screen, 
repeating this process all the way down to the bottom.” So movement was something 
to bear in mind: Dona decided to have the centipede automatically move from left 
to right, go down a row, turn, and then go the other way. By repeating this pattern, 
the centipede made its way from the top left of the screen to the bottom right. 

Now Dona needed to create some level of interaction. The player is 
stationed at the bottom of the screen and is able to fire lasers at the centipede as it 
travels down. On the original arcade version, the player could be moved left to right 
using the mini-trackball, as well as up and down within a limited range (“the player 


Learn from the master 

Centipede lent some natural constructions which meant that some parts of the gaming process were 
dealt with almost by accident. 

No time limit: Centipede didn’t need to have an obvious time limit because the act of the creature 
moving rapidly down the screen meant players couldn’t afford to take their time. 

No platforms: By having the enemy character move down the screen itself, there was no need for set 
platforms to be included - the randomly positioned mushrooms did the job perfectly. 
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couldn’t move higher than several rows from the bottom of the screen,” explains 
Dona). At the same time, it could only fire one shot at a time. 

“If the shot is in motion on the screen, then the player must wait until 
the shot graphic is returned to the player icon before being able to fire again,” 
Dona says. “The player can use a rapid fire option by keeping the firing button 
depressed. The shot returns to the player icon to be used again when it either shoots 
something on the screen, including some portion of the centipede, or when it gets 
to the top of the screen.” 

Every shot counts 

For players, this mechanic ensures that every shot is sacred. The centipede will be 
coming down at speed (exactly what speed you want for your fixed shooter game 

would be for you to work out in your code), so 
gamers will want every shot to have an impact. 
Missing wastes valuable time. 

When a shot hits the centipede, the 
segment it comes into contact with disappears. 
The segment behind it then becomes the 
centipede head, creating two centipedes. The 
trailing centipede moves down a row and heads 
the other way while the other part continues 
on its journey. “A player may shoot and cause 
the centipede to break into more than one 
centipede travelling in different directions on 
different rows of the screen,” says Dona. Players have to keep firing until the entire 
centipede is removed from the screen. 

For all of this to happen, the programmer has to carefully consider what is 
going on with the centipede when it is shot. To start with, each segment has to be 
treated as a separate entity. It’s not really one long centipede on the screen, but a set 
of individual components that act as one. You have to factor in that the sets have to 
move independently of each other after they are shot. And when they are shot and 
a piece disappears, you have to give the player another laser to fire. Bear in mind 
too that the player will be approaching the game in different ways. 

“Some players liked to practise strategies where they shot only the head of a 
centipede by carefully picking off the head each time a new head appeared,” notes 
Dona. “Other players liked to shoot randomly, hitting anything possible.” A game 
that can be played tactically works well for players, offering depth and giving the 
player the feeling that it is a skilful, beatable game full of secrets to unlock. 

Coding checks 

But how do you program all of this? Dona says for Centipede , the main creature, 
the player, and the shot had to be displayed on the screen at all times for each 
level of the game. Each round is then set up to display the graphics, the player 
icon, the shot, and the various colours that the centipede head and body segments 
can appear in (by changing the colour from one level to the next, you can very 
quickly add variety). “The status of the trackball for any player motions is checked 
repeatedly so as to react to a player’s intended movements,” says Dona. “The status 


A game that 
can be played 
tactically works 
well for players, 
offering depth 
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of the firing button is checked repeatedly so as to react to the player’s intentions of 
using the shot on screen.” 

Collision are detected next. “The centipede segments move incrementally at 
a steady rate in a consistent direction, and the program checks at each incremental 
movement for screen edges or for mushrooms,” Dona explains. Which takes us 
neatly to the part that allows the gameplay of Centipede to move up a notch by 
adding a very compelling twist: the obstacles that the centipede interacts with. 

Producing obstacles 

The mushrooms are crucial to gameplay, making the centipede’s behaviour more 
erratic. The game littered the screen with these obstacles, and the idea was that the 
centipede would hit one and be forced to move down a row much sooner than it 
would if the entire line had been clear. But Dona says the mushrooms in Centipede 

came about as a lucky accident. 

“I was learning as I worked. I made a lot 
of mistakes in the code I wrote and I also made 
a lot of bad estimations because everything 
attempted was my first try,” she says. “When I 
wrote the collision detection part of the code for 
the moving shot, I thought logically that I could 
just use arithmetic and count it as a hit if the 
shot actually touched a centipede head or body 
segment on the screen. I had no experience 
with how a collision looked compared to the 
arithmetic of an actual collision in numbers. 

“The first time I played this code to test 
it, I saw that it appeared, to my eyes, that a shot 
went straight through a centipede segment. It turns out that the area that must 
count as a collision in order to appear correct visually is much greater than the 
area of actual arithmetic for a collision. I kept adjusting and after a bit of time and 
experimenting, I believed I had a collision routine that appeared valid visually.” 

Her struggle with collisions had shaken her confidence, but one morning, 
soon after getting the collision detection working, she says she found herself with 
a couple of free hours when no one was pushing her to start on new features. “I 
decided to pause for a moment because I wanted to further 
reassure myself that I was correctly handling the breaking 
apart and turning of centipede segments after a segment 
had been shot. I wanted to take time out to put a visual 
marker on the screen where a segment was shot, and I 
wanted to play the game and be certain the remaining part 
of the centipede turned at the place where the visual marker 
was placed.” 

She made a simple black box graphic in an 8x8 
bitmap stamp pattern and wrote the code to place the black 
square where a centipede segment was shot. “I got the code 
compiled and a test PROM created and I raced back to 
the development cabinet to check it out,” recounts Dona. 


2 The centipede 
splits in two 
whenever it’s hit 
in the middle, 
often resulting in 
multiple enemies 
to deal with 

3 The Atari 2600 
version of the 
game features 
simplified 
graphics, but 
the gameplay is 
largely the same 


The first time I played 
this code to test it, I 
saw that it appeared, 
to my eyes, that a shot 
went straight through 
a centipede segment 


123 


Fixed Shooter - Centipede 


Fixed Shooter - Centipede 


CODE 

CLASSICS 


“I played the game and I was so relieved to see that the collision detection and 
subsequent movement of the centipede was working properly I continued to play 
because it was making me happy to see the interesting patterns that developed 
on the screen as I shot more and more centipede segments and more and more 
square boxes made an ever-changing maze pattern that broke up the screen nicely 
In just a few minutes, I understood that these test boxes had a lot of potential as a 
permanent feature.” 

New perspectives 

Stepping back from a project and looking at it from a player’s point of view can 
make you see the game from a different perspective, and remind you that you 
shouldn’t always stick to a firm path. The best games programming is creative and 
flexible, growing organically as you become more familiar with the basic constructs. 
By experimenting and testing, Dona decided to replace the 8x8 pixel squares with 
a better-looking graphic. 

She decided on rocks or boulders in brown at first, but dismissed them 
quickly. “It’s almost impossible to make a good-looking rock in 8x8 pixels, and 
combined with the brown colour it appeared that the screen was littered with 
poop.” She says she replaced them with simple mushrooms that had a cap and stem 
with an edge around them so she could use two colours for contrast. 

“This turned out to be beautiful in my view, and I played the game, 
scattering a held of the shimmering mushrooms,” Dona recalls. “Really tired 
from all the hurrying and effort of the morning, I left for lunch. By the time I 
came back, other guys in the coin-op department at Atari were playing Centipede 
and endorsing the addition of the mushrooms. The new feature had caught on and 
caused a little hurry of attention, and it was decided that the mushrooms could stay 
in the game.” 

But that wasn’t the end of the tweaking. “We had a lot of fun with the new 
feature for the remainder of the development of the game,” Dona continues. “We 
used the random number generator to vary the placement of the mushrooms when 
each new round is set up. After working for a long while with the mushrooms as 
permanent and non-eroding, we had the breakthrough idea during a game review 
to shoot the mushrooms away for points in order to clear the screen or to create 
new patterns.” 


The objectives 

Short term: Begin by moving the characters that are on the screen at all times or most of the time. 
This is likely to include the player icon. For example, in Centipede the first objective was to move the 
centipede, then the player icon, and then the icon for the shot. 

Medium term: Add other characters that appear less often; begin adding points for scoring; begin 
adding sound effects. 

Long term: Add complexity to gameplay,such as more difficult higher levels based on scoring higher 
points or longer playing times. Polish the pacing and fun factor of the game. Polish scoring, sounds, 
and graphics.Test for bugs in gameplayas much, and with as many players, as possible. 
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Enemy movement 

By shooting at the mushrooms, it was possible to prevent the centipede from 
moving down the screen too quickly But before she had even got to work on the 
mushrooms, Dona had looked to increase the number of things a player had to deal 
with. She introduced a spider which moves at the bottom of the screen in diagonal 
directions, at angles and in time intervals that vary at random. 

“Atari’s custom sound chip contained a random number generator 
that I used to add variety to the spider’s movement and timing so that each 
appearance of the spider is unpredictable, keeping gameplay fresh,” she reveals. 
“I was taught and guided how to implement much of Centipede 's gameplay by more 
experienced programmers at Atari, and I benefited greatly from the advice and 

help of others, but using the random number 
generator in Centipede was my idea. I think 
the introduction of unpredictability makes the 
game more fun.” 

Because the system could only support 
16 motion objects on the screen at one time, at 
least one centipede segment must be shot prior 
to bringing out the spider. “Until at least one 
centipede segment is shot, all motion objects 
are in use on the screen. When a centipede 
section is shot and removed from the screen, its 
unused motion object can then be utilised for the spider.” But even with the spider 
in place, the management team in the coin-op department wanted more. 

“Management generally liked the game, but there was a consensus that 
Centipede needed ‘more’,” says Dona. “More what?, we wondered. I seized on what 
it didn’t have at the time, which was something that moved straight down the screen 
and something that moved straight across the screen, and that’s how the ant (I 
believed I drew an ant, but it was immediately known as a flea) with its vertical 
movement and the scorpion with its horizontal movement were born. These two 
added challenge and difficulty in more advanced levels of the game.” 

More creatures meant more complexity, including the option to manipulate 
the mushrooms to work with these extra creatures. “After the decision to shoot away 
the mushrooms, we were able to add mushroom-related features to the ant, which 
lays down a column of new mushrooms, and to the scorpion, which poisons a row 
of mushrooms, and each poisoned mushroom causes the centipede to go into a 
free-fall on the screen after touching one.” 

Awarding points 

In keeping with most games at the time, points were also awarded to players. They 
would gain a set number whenever a segment of the centipede was shot or if 
another creature was gunned down. There would be more points for mushrooms 
removed. A high score stayed on the screen along with the current player’s score, 
and this incentivised gamers to try to beat the highest points tally. 

“I believe that earning points and keeping score are elemental to any type 
of defined game, and I think most players enjoy the aspect of scoring and earning 
points,” says Dona. “I think it’s fun to offer some easily earned low-value points, as 


I think most 
players enjoy the 
aspect of scoring 
and earning points 
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Women in gaming 

Back in the early days of games programming, too few women were employed as programmers. Carol 
Shaw is believed to have paved the way in 1978 when she joined Atari as Microprocessor Software 
Engineer before going on to work at Tandem Computers and Activision, but Dona Bailey was still the 
only woman in the coin-op division when she joined.Today, the situation is thankfully getting better. 
Amy Hennig,who was heavily involved in the acclaimed Uncharted series, is among many highly 
influential women in gaming. Robin Hunicke has produced some of gaming’s most inspiring and 
creative titles, including the award-winning multiplayer co-op adventure game Journey. 


well as some risky high-value points. Game creators should 
remember to offer those easy points but build in some 
difficult points in order to tie in with a maxim attributed to 
Nolan Bushnell, founder of Atari, stating that games should 
be easy to learn but hard to master.” 

Centipede embodied that maxim: a pick-up-and-play title that translated well 
to consoles and joystick controls while lending the right dose of challenge and 
frustration to ensure players would keep going (or, in the case of the arcades, pump 
more money into the machines). It was a major triumph for Dona Bailey and co¬ 
creator Ed Logg and it brought fresh thinking to the shoot-’em-up genre. There 
are principles and concepts of gaming embedded in Centipede that can translate to 
many other games. 

“When making a game, it’s difficult for the programmer to back away 
from the familiar gameplay and weigh the 
game’s strengths and weaknesses in order to 
revise and balance overall features,” concludes 
Dona. “In 1980 when I worked on Centipede , I 
had played very few video games for only short 
amounts of time, and the held of game studies 
was unheard of at that point. Today’s game 
programmers can play a wide variety of games, 
apply critical thinking to each game in order to 
carefully analyse its features, and study game 
programming as well as game studies.” 

Dona advises you to enlist your friends, 
family, and critical game players as helpers. “In addition to formal studies, it’s 
helpful to ask others to play your game, and it’s also helpful if you ask other players 
to complete a questionnaire or to write responses on features you are testing,” she 
says. “Game programmers learn to adjust and balance game features by playing 
other games, by consulting with other players, and by extensively practising the art 
of game development. Remember that every skill worth cultivating improves with 
extensive practice, and this is certainly true for game development.” 


It's difficult for the 
programmer to weigh 
the game’s strengths 
and weaknesses 


4 A flyer for the 
1980 arcade 
game features a 
female player 
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M yriapod is our homage to Centipede. In this 
version of the game, the mushrooms 
have become rocks and the spider is a 
flying insect. The centipede is referred to 
as a myriapod — a word that categorises 
animals such as centipedes and 
millipedes. We’ve created classes for each of these, named 
Rock and FlyingEnemy. The classes inherit from Pygame 
Zero’s Actor class, which keeps track of an object’s location 
in the game world, as well as taking care of loading and 
displaying sprites. There’s also an Explosion class, used 
when a bullet is destroyed. 

The myriapod itself, rather than being a single 
entity, is made of multiple instances of the Segment class 
- each of which moves independently of the others, even 
if it may not initially look like it when they come onto the 
screen in a nice tidy row. The Player class handles player 
movement and animation, as well as dealing with what 


Download the code 

Download the fully commented Myriapod game code, along with 
all the graphics and sounds, from wfmag.cc/CTCl-myriapod 
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happens when the player is destroyed and then respawns. It also handles the creation 
of Bullets. 

The Game class is responsible for creating the flying enemy, the myriapod 
segments, and most of the rocks. It also maintains a reference to the player object, 
and creates a two-dimensional list to represent the grid - where each element is either 
a reference to a Rock object or the value None, which indicates there is no rock at this 
grid location. The Game class contains many key methods which are called from other 
parts of the game, such as allow_movement which ensures the player cannot drive 
through rocks. 

The update and draw functions read the state variable and run only the 
code relevant to the current state. The game variable references an instance of the 

Game class as described above. The_init_(constructor) method of Game optionally 

receives a parameter named player. When we create a new Game object for the 
main menu, we don’t provide this parameter, and the game will therefore run in 
attract mode. When we create a new Game object for the game itself, we supply a new 
Player object. 

Segment movement 

The most complex code in this game relates to how myriapod segments move, and 
how they decide where to go next. Each segment moves in relation to its current 
grid cell. A segment enters a cell from a particular edge (stored in in_edge in the 
Segment class). After five frames, it decides which edge it’s going leave through (stored 
in out_edge). For example, it might carry straight on and leave through the opposite 
edge from the one it started at. Or it might turn 90 degrees and leave through an edge 
to its left or right. In the latter it initially turns 45 degrees and continues along that 
path for eight frames. It then turns another 45 degrees, at which point it is heading 
directly towards its next grid cell. A segment spends a total of 16 frames in each cell. 
Within the update method, the variable phase refers to where it is in that cycle — 0 
meaning it’s just entered a grid cell, and 15 meaning it’s about to leave it. 

Let’s first imagine the case where a segment enters from the top edge of a cell 
and carries on in a straight line, eventually leaving from the bottom edge (Figure 1). 
Grid cells are 32x32 pixels, and segments take either 16 or 8 frames to travel through 
a cell (every fourth wave of myriapods is fast). For normal-speed segments, this means 
they just need to move two pixels in the relevant direction each frame. 


Player sprite animation 

When the player presses a key to start heading in a new direction, 
we don't want the sprite to just instantly change to facing in that 
new direction.That would look wrong, since in the real world 
vehicles can't just suddenly change direction in the blink of an 
eye. Instead, we want the vehicle to turn to face the new direction 
over several frames. For example, if the vehicle is currently facing 
down, and the player presses the left arrow key, the vehicle should 
first turn to face diagonally down and to the left, and then turn to 
face left. 
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Figure 1 


Figure 2 


in edge: DIRECTION_UP 




Let’s now imagine the case where a segment enters from the left edge of a cell 
and then turns to leave from the bottom edge (Figure 2). The segment will initially 
move along the horizontal (X) axis, and will end up moving along the vertical (Y) axis. 
In this case we’ll call the X axis the primary axis, and the Y axis the secondary axis. It 
starts out moving at two pixels per frame on the primary axis, but then starts moving 
along the secondary axis based on the values in the list SECONDARY_AXIS_POSITIONS - 
which stores the total secondary axis movement that will have occurred at each phase 
in the segment’s movement through the current grid cell. In this case we don’t want it 
to continue moving along the primary axis — it should initially slow to moving at one 
pixel per frame (the diagonal part of the segment’s movement), and then stop moving 
along that axis completely. In effect, the secondary axis steals movement from the 
primary axis — hence the variable stolen_y_movement. 

The code starts off with the assumption that a segment is starting from the 
top of the cell. The primary and secondary axes would therefore be Y and X. Later, 
a calculation is applied to rotate these X and Y offsets, based on the actual direction 
the segment is coming from. 

These are the essentials of how segments move — you can find more detail 
in the fully commented code at wfmag.cc/CTCl-myriapod. But how does a 
segment choose which cell it’s going to move into next? 

Although the myriapod initially looks like it moves as one unit, the individual 
segments are actually independent of each other. This becomes clear when you 
shoot a segment in the middle. Destroyed segments turn into rocks, which causes the 
segments behind to change direction and split off from the front segments. 

As described above, each segment has a phase variable which indicates where 
it’s at in its movement through its current grid cell. In the update method, when phase 
reaches 4, a decision needs to be made as to which grid cell it’s going to try to move 
into next — and therefore, which edge of the current cell it will leave via, to be stored 
in out_edge. 
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Making waves 

At the start of the game, or each time the player has 
destroyed all myriapod segments, a new wave is started. 

This occurs in the Game. update method.The first 
thing that happens is that rocks are randomly created 
throughout the level. Although we could create them all 
in one go, it’s more aesthetically pleasing to create one 
per frame until we have the desired number. Once we 
have enough rocks (a number that increases each wave), 
we move on to creating the myriapod itself. Initially 
we create eight segments per myriapod, but every four 
waves this number increases by two.The segments are created just off the top left corner of the screen. 
In the first wave, we create a basic myriapod where each segment takes one hit to kill. On the second 
wave, every other segment takes two hits to kill. On the third, all segments take two hits. On the fourth, 
the segments take only one hit, but they move twice as fast.This sequence then repeats, but with a 
longer myriapod. 



The rank method is key to understanding the decision-making process. Its 
purpose is to rank the possible directions in which a segment could move, in order 
of preference. It contains an inner/nested function, named inner, which it returns 
as its result. The returned function is passed to Python’s min function in the update 
method, as the ‘key’ optional parameter, min then calls this function four times with 
the numbers 0 to 3, representing the four possible directions (see DIRECTION_UP etc., 
further up the code). We’ll explain shortly why and how we’re using min. 

The inner function takes one parameter named proposed_out_edge, 
representing a direction. The function returns a tuple consisting of a series of factors 
determining which grid cell the segment should try to move into next. These are not 
absolute rules — rather, they are used to rank the four directions in order of preference, 
i.e. which direction is the best (or at least, least bad) to move in. The factors are 
Boolean (True or False) values. A value of False is preferable to a value of True. The 
order of the factors in the returned tuple determines their importance in deciding 
which way to go, with the most important factor coming first. Some examples of 
these factors are that a segment shouldn’t try to go in a direction that takes it outside 
the grid, it shouldn’t try to go through a rock unless absolutely necessary (in which 
case the rock will be destroyed), and it should usually prefer to move horizontally. 

Back in the update method, range(4) generates all the numbers from 0 to 3 
(corresponding to DIRECTION_UP etc). Python’s built-in min function usually chooses 
the lowest number that it’s given, so would usually return 0 as the result. But if the 
optional key argument is specified, this changes how the function determines the 
result. The inner function returned by the rank function is called by min to decide how 
the items should be ordered. The inner function returns a tuple of Boolean values 
- e.g. (True,False,False,True). When Python compares two such tuples, it considers 
values of False to be less than values of True, and values that come earlier in the 
sequence are more significant than later values. So (False,True) would be considered 
less than (True,False). Since it’s min rather than max we’re calling, the end result of all 
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this is that out_edge will be set to the direction which corresponds to the tuple with 

the lowest value. 

The elements of the tuple are as follows: 

• Does the proposed direction take us to a cell outside the grid? 

• Does it take us back on ourselves - a 180 degree turn? 

• Does it take us in a direction that’s disallowed? (Can’t go down if we’re on the 
bottom row of the grid, can’t go up if we’re on row 18) 

• Is there a rock in the new cell? 

• Is the new cell already occupied by another segment, or is another segment 
trying to enter my cell from the opposite direction? 

• A factor causing us to prefer to move horizontally, unless there's a rock in the way 
If there are rocks both horizontally and vertically, we prefer to move vertically 

• A factor causing us to change direction from left to right and vice versa each time 
we move up or down. 


Challenges 


■ In the original Centipede, only one bullet can exist at a time, and the player can fire again as soon as 
the current bullet is destroyed. If the player holds down the fire button, the fire rate will be very rapid 
while repeatedly shooting targets close to the player, and slower when shooting more distant targets. 
How would you achieve this behaviour in Myriapod ? 


■ How would you change the code so that a wave could consist of multiple myriapods - created either 
simultaneously or at intervals? 


■ Currently, shooting a ‘Totem’ rock gives a score bonus, but what if it also dropped a power-up which 
could be collected - temporarily giving the player three bullets at once, for example? 


■ Award an extra life when the player scores 1000 points, then another after another 1200 points, then 
1400, and so on. Play a sound effect when an extra life is gained. 


■ Keep track of the high score and save new high scores to a file, in a similar way to Bunner. On the 
game-over screen, display the player’s score and either the current high score if it hasn’t been beaten, 
or'NEWHIGH SCORE!’ 
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How to run the game 

Open the myriapod.py file in a Python editor,such as IDLE,and select Run > Run Module. 
For more details, see the ‘Setting up’section on page 186. 


Download the code wfmag.cc/CTi 


001. 
002 . 
003 . 
004 . 
005 . 
006 . 
007 . 
008 . 
009 . 
010 . 
011 . 
012 . 
013 . 
014 . 
015 . 
016 . 
017 . 
018 . 
019 . 
020 . 
021 . 
022 . 
023 . 
024 . 
025 . 
026 . 
027 . 
028 . 
029 . 
030 . 
031 . 
032 . 
033 . 
034 . 
035 . 
036 . 
037 . 
038 . 
039 . 
040 . 


import pgzero, pgzrun, pygame, sys 

from random import choice, randint, random 

from enum import Enum 

if sys.version_info < (3,5): 

print("This game requires at least version 3.5 of Python. Please download" 
"it from www.python.org") 
sys.exit() 

pgzero_version = [int(s) if s.isnumeric() else s 

for s in pgzero._version_.split('.')] 

if pgzero_version < [1,2]: 

print("This game requires at least version 1.2 of Pygame Zero. You are" 

"using version {pgzero._version_}. Please upgrade using the command" 

"'pip install —upgrade pgzero'") 
sys.exit() 

WIDTH = 480 
HEIGHT = 800 
TITLE = "Myriapod" 

DEBUG_TEST_RANDOM_POSITIONS = False 
CENTRE_ANCHOR = ("center", "center") 

num_grid_rows = 25 
num_grid_cols = 14 

def pos2cell(x, y): 

return ((int(x)-l 6)//32, int(y)//32) 

def cell2pos(cell_x, cell_y, x_offset=0, y_offset=0): 

return ((cell_x * 32) + 32 + x_offset, (cell_y * 32) + 16 + y_offset) 

class Explosion(Actor) : 

def _init_ (self, pos, type): 

super(). _init_. ("blank", pos) 
self. type = type 
self. timer = 0 

def update(self ): 
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041 . 
042 . 
043 . 
044 . 
045 . 
046 . 
047 . 
048 . 
049 . 
050 . 
051 . 
052 . 
053 . 
054 . 
055 . 
056 . 
057 . 
058 . 
059 . 
060 . 
061 . 
062 . 
063 . 
064 . 
065 . 
066 . 
067 . 
068 . 
069 . 
070 . 
071 . 
072 . 
073 . 
074 . 
075 . 
076 . 
077 . 
078 . 
079 . 
080 . 
081 . 
082 . 
083 . 
084 . 
085 . 
086 . 
087 . 


self. timer += 1 

self. image = "exp" + str(self .type) + str(self. timer // 4) 

class Player(Actor) : 

INVULNERABILITY.TIME = 100 
RESPAWN.TIME = 100 
RELOAD.TIME = 10 

def _init. (self, pos): 

super(). _init_ ("blank", pos) 

self .direction = 0 
self. frame = 0 
self. lives = 3 
self. alive = True 
self. timer = 0 
self .fire_timer = 0 

def move(self, dx, dy, speed): 
for i in range(speed) : 

if game. allow_movement (self .x + dx, self.y + dy): 
self.x += dx 
self.y += dy 

def update(self): 
self. timer += 1 

if self. alive: 
dx = 0 

if keyboard.left: 
dx = -1 

elif keyboard.right: 
dx = 1 


dy = 0 

if keyboard.up: 
dy = -1 

elif keyboard.down: 
dy = 1 


self .move(dx, 0, 3 - abs(dy)) 
self.move(0, dy, 3 - abs(dx)) 
directions = [7,0,1,6,-1,2,5,4, 3] 
dir = directions[dx+3*dy+4] 

if self. timer % 2 == 0 and dir >= 0: 
difference = (dir - self .direction) 
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088 . 
089 . 
090 . 
091 . 
092 . 
093 . 
094 . 
095 . 
096 . 
097 . 
098 . 
099 . 
100 . 
101 . 
102 . 

103 . 

104 . 

105 . 

106 . 

107 . 

108 . 

109 . 

110 . 
Ill . 
112 . 

113 . 

114 . 

115 . 

116 . 

117 . 

118 . 

119 . 

120 . 
121 . 
122 . 

123 . 

124 . 

125 . 

126 . 

127 . 

128 . 

129 . 

130 . 
131 . 

132 . 

133 . 

134 . 


rotation_table = [0, 1, 1, -1] 

rotation = rotation_table[difference % 4] 

self .direction = (self .direction + rotation) % 4 

self .fire_timer -= 1 

if self .fire_timer < 0 and (self. frame > 0 or keyboard.space): 
if self. frame == 0: 

game. play_sound( "laser" ) 

game.bullets. append(Bullet((self.x, self.y - 8))) 
self. frame = (self. frame + 1) % 3 
self .fire_timer = Player. RELOAD_TIME 

all_enemies = game.segments + [game.flying_enemy] 

for enemy in all_enemies: 

if enemy and enemy .collidepoint(self.pos): 

if self. timer > Player. INVULNERABILITY.TIME: 
game.play_sound("player_explode") 
game.explosions. append(Explosion (self .pos, 1 )) 
self. alive = False 
self. timer = 0 
self. lives -= 1 

else: 

if self. timer > Player. RESPAWN.TIME: 
self. alive = True 
self. timer = 0 
self. pos = (240, 768) 
game. clear_rocks_for_respawn(*self .pos) 

invulnerable = self. timer > Player.INVULNERABILITY.TIME 
if self. alive and (invulnerable or self. timer % 2 == 0): 

self. image = "player" + str(self .direction) + str(self .frame) 
else: 

self. image = "blank" 

class FlyingEnemy(Actor) : 

def _init_ (self, player_x): 

side = 1 if player_x < 160 else 0 if player_x > 320 else randint(0, 1) 

super() . __init__ ("blank , (550*side-35, 688)) 

self .moving_x = 1 

self.dx = 1 - 2 * side 

self.dy = choice([-1, 1]) 

self. type = randint(0, 2) 

self. health = 1 

self. timer = 0 
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135 . 

136 . 

137 . 

138 . 

139 . 

140 . 
141 . 

142 . 

143 . 

144 . 

145 . 

146 . 

147 . 

148 . 

149 . 

150 . 
151 . 

152 . 

153 . 

154 . 

155 . 

156 . 

157 . 

158 . 

159 . 

160 . 
161 . 
162 . 

163 . 

164 . 

165 . 

166 . 

167 . 

168 . 

169 . 

170 . 
171 . 

172 . 

173 . 

174 . 

175 . 

176 . 

177 . 

178 . 

179 . 

180 . 
181 . 


def update(self): 
self. timer += 1 

self.x += self.dx * self .moving_x * (3 - abs(self .dy)) 
self.y += self.dy * (3 - abs(self.dx * self .moving_x)) 

if self.y < 592 or self.y > 784: 
self .moving_x = randint(0, 1) 
self.dy = -self.dy 

anim_frame = str([0, 2, 1, 2][(self. timer // 4) % 4]) 
self. image = "meanie" + str(self .type) + anim_frame 

class Rock(Actor): 

def _init_ (self, x, y, totem=False) : 

anchor = (24, 60) if totem else CENTRE.ANCHOR 

super(). _init_ ("blank", cell2pos(x, y), anchor=anchor) 

self. type = randint(0, 3) 

if totem: 

game. play_sound(" totem_create" ) 
self. health = 5 
self .show_health = 5 
else: 

self. health = randint(3, 4) 
self .show_health = 1 

self. timer = 1 

def damage(self, amount, damaged_by_bullet=False) : 
if damaged_by_bullet and self. health == 5: 
game. play_sound (" totem_dest roy" ) 
game.score += 100 
else: 

if amount > self. health - 1: 

game. play_sound ( "rock_dest roy" ) 
else: 

game.play_sound("hit" , 4) 

game.explosions. append(Explosion(self .pos, 2 * (self. health == 5))) 

self. health -= amount 

self .show_health = self. health 

self. anchor, self. pos = CENTRE_ANCFIOR, self. pos 

return self. health < 1 

def update(self ): 
self. timer += 1 
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182 . 

183 . 

184 . 

185 . 

186 . 

187 . 

188 . 

189 . 

190 . 
191 . 

192 . 

193 . 

194 . 

195 . 

196 . 

197 . 

198 . 

199 . 

200 . 
201 . 
202 . 

203 . 

204 . 

205 . 

206 . 

207 . 

208 . 

209 . 

210 . 
211 . 
212 . 

213 . 

214 . 

215 . 

216 . 

217 . 

218 . 

219 . 

220 . 
221 . 
222 . 

223 . 

224 . 

225 . 

226 . 

227 . 

228 . 


if self. timer % 2 == 1 and self .show_health < self. health: 
self .show_health += 1 

if self. health == 5 and self. timer > 200: 
self .damage(1) 

colour = str(max(game.wave, 0) % 3) 

health = str(max(self.show_health - 1, 0)) 

self. image = "rock" + colour + str(self .type) + health 

class Bullet(Actor) : 

def _init_ (self, pos): 

super(). __init_ ("bullet" , pos) 

self. done = False 

def update(self ): 
self.y -= 24 

grid_cell = pos2cell(*self.pos) 

if game.damage(*grid_cell, 1, True): 

self. done = True 
else: 

for obj in game.segments + [game.flying_enemy]: 
if obj and obj. collidepoint(self .pos): 

game.explosions. append(Explosion(obj .pos, 2)) 
obj.health -= 1 

if isinstance(obj , Segment): 
if obj.health == 0 \ 

and not game.grid[obj.cell_y][obj.cell_x] \ 
and game. allow_movement (game.player.x, \ 

game.player.y, obj.cell_x, obj.cell_y): 

rock = Rock(obj .cell_x, obj.cell_y, random() < .2) 
game.grid[obj.cell_y][obj.cell_x] = rock 

game. play_sound( "segment_explode" ) 
game.score += 10 
else: 

game. play_sound( "meanie_explode" ) 
game.score += 20 

self. done = True 

return 
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229. 

230. SECONDARY_AXIS_SPEED = [0]*4 + [1]*8 + [2]*4 

231. SECONDARY_AXIS_POSITIONS = [sum(SECONDARY_AXIS_SPEED[:i]) for i in range(16)] 

232. 

233. DIRECTIONJJP = 0 

234. DIRECTION.RIGHT = 1 

235. DIRECTION JJOWN = 2 

236. DIRECTION J_EFT = 3 

237. 

238. DX = [0,1,0,-1] 

239. DY = [-1,0,1,0] 

240. 

241. def inverse_direction(dir) : 

242. if dir == DIRECTIONJJP: 

243. return DIRECTION.DOWN 

244. elif dir == DIRECTION.RIGHT: 

245. return DIRECTION.LEFT 

246. elif dir == DIRECTION JJOWN: 

247. return DIRECTIONJJP 

248. elif dir == DIRECTIONJ_EFT: 

249. return DIRECTION.RIGHT 


250. 
251 . 

252. 

253. 

254. 

255. 

256. 

257. 

258. 

259. 

260. 
261 . 
262. 

263. 

264. 

265. 

266. 

267. 

268. 

269. 

270. 
271 . 

272. 

273. 

274. 

275. 


def is_horizontal(dir) : 

return dir == DIRECTIONJ_EFT or dir == DIRECTION.RIGHT 


class Segment(Actor) : 

def _init. (self, cx, cy, health, fast, head): 

super (). _init_ ("blank" ) 


def rank(self): 


def inner(proposed_out_edge) : 

new_cell_x = self.cell_x + DX[proposed_out_edge] 
new_cell_y = self.cell_y + DY[proposed_out_edge] 


self .disallow_direction = DIRECTIONJJP 
self .previous_x_direction = 1 


self. fast = fast 
self. head = head 


self. in_edge = DIRECTION J_EFT 
self .out_edge = DIRECTION.RIGHT 


self. health = health 


self.cell_x = cx 
self.cell_y = cy 


out = new_cell_x < 0 or new_cell_x > num_grid_cols - 1 \ 
or new_cell_y > 0 or new_cell_y > num_grid_rows - 1 
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276. 

277. 

278. 

279. 

280. 
281 . 
282. 

283. 

284. 

285. 

286. 

287. 

288. 

289. 

290. 
291 . 

292. 

293. 

294. 

295. 

296. 

297. 

298. 

299. 

300. 
301 . 

302. 

303. 

304. 

305. 

306. 

307. 

308. 

309. 

310. 
311 . 

312. 

313. 

314. 

315. 

316. 

317. 

318. 

319. 

320. 
321 . 
322. 


turning_back_on_self = proposed_out_edge == self.in_edge 
direction_disallowed = proposed_out_edge == self .disallow_direction 

if out or (new_cell_y == 0 and new_cell_x < 0): 

rock = None 
else: 

rock = game.grid[new_cell_y][new_cell_x] 
rock_present = rock != None 

occupied_by_segment = (new_cell_x, new_cell_y) in game.occupied \ 
or (self .cell_x, self.cell_y, proposed_out_edge) in game.occupied 

if rock_present: 

horizontal_blocked = is_horizontal(proposed_out_edge) 
else: 

horizontal_blocked = not is_horizontal(proposed_out_edge) 

same_as_previous_x_direction = \ 

proposed_out_edge == self .previous_x_direction 

return (out, turning_back_on_self, direction_disallowed, \ 

occupied_by_segment, rock_present, horizontal_blocked, \ 
same_as_previous_x_direction) 


return inner 


def update(self ): 

phase = game.time % 16 


if phase == 0: 
self.cell_x += 
self.cell_y += 
self.in_edge = 


DXEself .out_edge] 

DYEself .out_edge] 
inverse_direction (self .out_edge) 


if self.cell_y == (18 if game.player else 0): 

self .disallow_direction = DIRECTIONJJP 
if self.cell_y == num_grid_rows-1: 

self .disallow_direction = DIRECTI0N_D0WN 
elif phase == 4: 

self .out_edge = min(range(4) , key = self.rankQ) 


if is_horizontal(self .out_edge): 

self .previous_x_direction = self .out_edge 


new_cell_x = self.cell_x + DXEself .out_edge] 
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323. 

324. 

325. 

326. 

327. 

328. 

329. 

330. 

331. 

332. 

333. 

334. 

335. 

336. 

337. 

338. 

339. 

340. 

341. 

342. 

343. 

344. 

345. 

346. 

347. 

348. 

349. 

350. 
351 . 

352. 

353. 

354. 

355. 

356. 

357. 

358. 

359. 

360. 

361. 

362. 

363. 

364. 

365. 

366. 

367. 

368. 

369. 


new_cell_y = self.cell_y + DY[self .out_edge] 

if new_cell_x >= 0 and new_cell_x < num_grid_cols: 
game. damage (new_cell_x, new_cell_y, 5) 

game.occupied. add( (new_cell_x, new_cell_y)) 
game.occupied.add((new_cell_x, new_cell_y, \ 

inverse_direction (self .out_edge))) 

turn_idx = (self .out_edge - self .in_edge) % 4 

offset.x = SECONDARY_AXIS_POSITIONS[phase] * (2 - turn.idx) 
stolen_y_movement = (turn_idx % 2) * SECONDARY_AXIS_POSITIONS[phase] 
offset_y = -16 + (phase * 2) - stolen_y.movement 

rotation.matrices = [[1 ,0,0,1 ], [0,-1,1 ,0],[-1 , 0 , 0 , -1 ], [0,1 ,-1 ,0]] 
rotation.matrix = rotation_matrices[self.in.edge] 
offset.x, offset.y = offset.x * rotation_matrix[0] \ 

+ offset.y * rotation_matrix[1], \ 
offset.x * rotation_matrix[2] \ 

+ offset.y * rotation_matrix[3] 

self.pos = cell2pos(self.cell_x, self.cell.y, offset.x, offset.y) 

direction = ((SECONDARY_AXIS_SPEED[phase] * (turn.idx - 2)) \ 

+ (self .in.edge * 2) + 4) % 8 

leg.frame = phase // 4 

self. image = "seg" + str(int(self.fast)) + str(int(self.health == 2)) \ 
+ str(int(self.head)) + str(direction) + str(leg_frame) 


class Game: 

def _init_ (self, player=None) : 

self. wave = -1 
self. time = 0 
self. player = player 

self. grid = [[None] * num_grid_cols for y in range(num_grid_rows)] 

self. bullets = [] 

self .explosions = [] 

self .segments = [] 

self .flying.enemy = None 

self. score = 0 

def damage(self, cell.x, cell.y, amount, from_bullet=False) : 
rock = self .grid[cell_y][cell_x] 
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370. 
371 . 

372. 

373. 

374. 

375. 

376. 

377. 

378. 

379. 

380. 
381 . 

382. 

383. 

384. 

385. 

386. 

387. 

388. 

389. 

390. 
391 . 

392. 

393. 

394. 

395. 

396. 

397. 

398. 

399. 

400. 
401 . 

402. 

403. 

404. 

405. 

406. 

407. 

408. 

409. 

410. 
411 . 

412. 

413. 

414. 

415. 

416. 


if rock != None: 

if rock.damage(amount , from_bullet): 
self .grid[cell_y][cell_x] = None 

return rock != None 

def allow_movement(self , x, y, ax=-1 , ay=-1): 

if x < 40 or x > 440 or y < 592 or y > 784: 
return False 

x0, y0 = pos2cell(x-1 8, y-10) 
xl, yl = pos2cell(x+18, y+10) 

for yi in range(y0, y1 +1 ): 
for xi in range(x0, xl+1): 

if self .grid[yi][xi] or xi == ax and yi == ay: 
return False 

return True 

def clear_rocks_for_respawn(self , x, y): 
x0, y0 = pos2cell(x-1 8, y-10) 
xi, yi = pos2cell(x+1 8, y+10) 

for yi in range(y0, y1 +1 ): 
for xi in range(x0, xl+1): 
self .damage(xi , yi, 5) 

def update(self ): 

self. time += (2 if self. wave % 4 == 3 else 1) 
self .occupied = set() 

all_objects = sum(self .grid, self. bullets + self .segments \ 

+ self .explosions + [self .player] + [self .flying_enemy]) 

for obj in all_objects: 
if obj: 

obj .update() 

self. bullets = [b for b in self. bullets if b.y > 0 and not b.done] 
self .explosions = [e for e in self .explosions if not e.timer == 31] 
self .segments = [s for s in self .segments if s.health > 0] 

if self .flying_enemy: 

if self .flying_enemy.health <= 0 or self .flying_enemy.x < -35 \ 
or self .flying_enemy.x > 515: 
self .flying_enemy = None 
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417. 

418. 

419. 

420. 
421 . 

422. 

423. 

424. 

425. 

426. 

427. 

428. 

429. 

430. 
431 . 

432. 

433. 

434. 

435. 

436. 

437. 

438. 

439. 

440. 
441 . 

442. 

443. 

444. 

445. 

446. 

447. 

448. 

449. 

450. 
451 . 

452. 

453. 

454. 

455. 

456. 

457. 

458. 

459. 

460. 
461 . 

462. 

463. 


elif random() < .01 : 

self .flying_enemy = FlyingEnemy(self .player.x if self. player else 240) 

if self .segments == []: 
num_rocks = 0 
for row in self. grid: 
for element in row: 
if element != None: 
num_rocks += 1 

if num_rocks < 31+self .wave: 
while True: 

x, y = randint(0, num_grid_cols-1), randint(1 , num_grid_rows-3) 
if self .grid[y][x] == None: 
self .grid[y][x] = Rock(x, y) 
break 

else: 

game. play_sound("wave") 
self. wave += 1 
self. time = 0 
self .segments = [] 

num_segments = 8 + self. wave // 4 * 2 
for i in range(num_segments): 

if DEBUG_TEST_RANDOM_POSITIONS : 

cell_x, cell_y = randint(1 , 7), randint(1 , 7) 
else: 

cell_x, cell_y = -1-i, 0 

health = [[1,1],[1,2],[2,2],[1,1 ]][self .wave % 4] [i % 2] 
fast = self. wave % 4 == 3 
head = i == 0 

self .segments. append(Segment(cell_x, cell_y, health, fast, head)) 
return self 
def draw(self): 

screen. blit("bg" + str(max(self.wave, 0) % 3), (0, 0)) 

all_objs = sum(self.grid, self. bullets + self .segments + self .explosions \ 
+ [self .player]) 

def sort_key(obj) : 

return (isinstance(obj , Explosion), obj.y if obj else 0) 

all_objs.sort(key=sort_key) 
all_objs. append (self .flying_enemy) 

for obj in all_objs: 
if obj: 
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obj .draw() 

def play_sound(self , name, count=1): 
if self. player: 
try: 

sound = getattr(sounds, name + str(randint(0, count - 1))) 
sound.play() 
except Exception as e: 
print(e) 

space_down = False 

def space_pressed() : 
global space_down 
if keyboard.space: 
if not space_down: 
space_down = True 
return True 

else: 

space_down = False 
return False 

class State(Enum): 

MENU = 1 , 

PLAY = 2, 

GAME.OVER = 3 

def update(): 

global state, game 

if state == State.MENU: 
if space_pressed() : 
state = State.PLAY 
game = Game(Player((240, 768))) 

game. update() 

elif state == State. PLAY: 

if game.player.lives == 0 and game.player.timer == 100: 
sounds.gameover. play () 
state = State. GAME_0VER 
else: 

game. update( ) 

elif state == State. GAME.OVER: 
if space_pressed() : 
state = State. MENU 
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511. game = Game() 

512. 

513. def draw(): 

514. game.draw() 

515. 

516. if state == State. MENU: 

517. screen. blit("title" , (0, 0)) 

518. screen. blit("space" + str((game. time // 4) % 14), (0, 420)) 

519. 

520. elif state == State. PLAY: 

521. for i in range(game. player.lives): 

522. screen. blit("life" , (i*40+8, 4)) 

523. 

524. score = str(game. score) 

525. 

526. for i in range(1 , len(score)+1 ): 

527. digit = score[-i] 

528. screen. blit("digit"+digit, (468-i*24, 5)) 

529. 

530. elif state == State. GAME.OVER: 

531. screen. blit("over" , (0, 0)) 

532. 

533. try: 

534. pygame.mixer .quit() 

535. pygame.mixer. init (441 00, -16, 2, 1024) 

536. 

537. music. play(" theme" ) 

538. music.set_volume(0.4) 

539. except: 

540. pass 

541. 

542. state = State. MENU 

543. game = Game() 

544. 

545. pgzrun.goQ 
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4 One of the three 
shades of cracked 
earth backdrop 

5 The title graphic 
is shown on the 
starting screen 

6 Rather than 
mushrooms, 
random rocks can 
be shot to clear 
them away 

7 The wheeled 
player sprite 
has rotated and 
shooting variants 
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Chapter 5 

Football Game 


Top-down games of pinball-style 
soccer built a huge cult following 
and kicked off a sports genre that's 
still going strong 



S ensible Soccer was a fast-paced, top-down, 
arcade-action football game, While it 
looked a far cry from the realistic soccer 
renditions of the likes of FIFA today, it 
quickly won a legion of fans. The top- 
down view allowed players to see more 
of the pitch as they knocked the ball from end to end, 
attacking and defending. It also allowed Sensible Software 
to be creative: the game’s greatest hallmark was arguably 
its tiny sprites, which not only ran like fury but were well- 
animated and responded elegantly to slide tackles and the 
other major physical aspects of the beautiful game. With 
an immersive atmosphere, underpinned by authentic live 
crowd noises, Sensible Soccer won huge popularity. 


Inspiration 

Sensible Soccer was created by Jon Hare and Chris Yates, 
who met during their school days. Having been in a band 
together, the pair began to code games, starting with 
the never-released Escape From Sainsbury’s , and their first 
commercial game, Twister: Mother of Charlotte. They formed 
their own development company in 1986 called Sensible 
Software and went on to produce commercial games 
including Parallax , Wizball, and SEUCK. The pair’s first 
stab at a football game came with Microprose Soccer in 1988. 
With other 1980s and 1990s staples like Mega Lo Mania , 
Wizkid, and Cannon Fodder in their stable, Hare and Yates 
are among Britain’s gaming heroes. 
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Sensible 


Released 


Platforms 


1993 


Amiga 
Atari ST 
Amiga CD32 
Acorn Archimedes 
Xbox Live Arcade 


Windows 
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Sensible Soccer was followed up two years later by Sensible World of Soccer, which 
included all of the professional leagues and competitions and also had a strong 
management element. 


Other Notables 


Microprose Soccer / Kick Off / Tehkan World Cup 


How are you watching the game? Are you high up in the stands at Wembley Stadium, 
soaking up the atmosphere of the crowd on a summer’s day, or are you wrapping 
up warm on the touchline in the pouring rain and shouting pleasantries in the park 
as the local Sunday league team get their usual thrashing? Perhaps you’re watching 
live on the television from the comfort of your armchair or listening to over-excited 
commentary on the car radio. Or maybe you’re playing a video game, in which case 
we’ll ask again: how are you viewing it? 

That’s because, over the years, many different developers have had their own 
take on the adaptation of football as a video game. There have been side-on, top- 
down, and isometric views, as well as games stripped down to their bare bones and 
games adorned with flashy overlaid graphics and stacks of menus. The first big soccer 
title, Pete’s Championship Soccer on the Atari 2600 in 1981, was a three-a-side affair 
which had players moving one block at a time. Real Sports Soccer finally introduced 
sprites which resembled humans a year later. But even though they were spartan, 
these games were unmistakably football. 

Games like the classic 8-bit title Match Day skipped real-life features: 
substitutions and team names were missing along with concepts like formations 
and referees, but they were still very recognisably football games. Back in the day, 
the goal for games developers was often to simply get players to knock the ball into 
the back of the net. As long as players could rack up the scores, everyone — it seemed 
— was happy. 

Compare Sensible Soccer to the top football games of today (so the likes of FIFA 
and Pro Evolution Soccer) and you’ll see exactly what we mean. The contemporary 
blockbuster titles like to view football as a televised game with commentary, 
on-screen graphics, close-ups of goal celebrations, and realistic physics embedded 
within players that look as close as possible to their real-life counterparts. Sensible 
Soccer , meanwhile, had tiny players scurrying around a pitch that was viewed from 
the top down. It felt almost as much like pinball as it felt like football, with the ‘ping, 
ping’ action of the ball being passed around the pitch at a breakneck speed. 

The mechanic worked spectacularly well. Sensible 
Soccer takes its place, even today, as one of the greatest football 
games ever produced in pixel form. What’s more, co-creator 
Jon Hare makes no apologies for the presentation and 
mechanics of the game: everything, he says, was deliberate 
and he’s pleased that it all worked out so well. “We used small 
sprites because that was our style at the time,” he says. “We 
had tiny characters and a bigger semi-overhead view of the 
environment when we were making Mega Ld Mania and when 
we realised they worked, we used them in Cannon Fodder and 


1 Fittingly, Sensible 
Soccer was a 
team effort, led 
by Jon Hare and 
Chris Chapman 

2 The Sensible 
Software team 
doing some 
research at a 
football stadium 
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3 Stuart‘Stoo’ 
Cambridge 
joined Sensible 
Software as a 
graphic artist 


Sensible Golf.” In fact, the first Sensible Soccer 
characters were Mega Lo Mania sprites with 
football kits on them. 

Kicking off 

Jon was the co-founder of Sensible Software, 
a company he formed with his friend Chris 
Yates. The pair had been introduced by a 
mutual friend when Jon was travelling back 
from a Rush concert in London and they 
became close. They had a shared love of music, and wrote and 
played songs together while they dreamed of becoming rock stars. 
Chris was studying computing at college. He would buy machines 
from a catalogue and spend a month frantically programming 
them. He’d then send them back, get a refund, and order a 
replacement. When money became even tighter, Chris took a job at LT Software 
and worked on a game called Sodov The Sorcerer for the ZX Spectrum. He asked Jon to 
create the artwork for it. That led to Jon being taken on too. 

The pair worked on a number of games, including Twister: Mother of Charlotte , 
but they decided they would make more money if they left LT Software and set up their 
own company. They did so in March 1986, creating the games Parallax , Wizball, and 
Shoot-’Em-Up Construction Kit (SEUCK ). Their first football game was Microprose Soccer , 
which they made with a new team member called Martin Galway, and it astounded 
gamers with its introduction of speed, a rain effect, and aftertouch. Inspired by the 
arcade game Tehkan World Cup , players could swerve the 
ball after kicking, see much of what was around them 
on the pitch, and replay their goals. The top-down view 
worked a treat, as did the simple controls. 

This suited Jon. The staunch Norwich City fan 
had spent many an hour flicking plastic players around 
a metre-long felt Subbuteo pitch, so he was used to a 
bird’s-eye perspective of soccer. Another game, Kick 
Off.] already used the same viewpoint, but Jon and 
Chris Chapman, who had joined Sensible Software 
to work on Mega Lo Mania, felt they could do better. 

The team worked for nine solid months to ensure that 
Sensible Soccer was released in time for the 1992 UEFA 
European Football Championship. 

“We concentrated on the actual gameplay when we created Sensible Soccer ,” 
says Jon. “We didn’t go down the path of flashy presentation and the emphasis on 
style over substance, which we eventually saw when FIFA International Soccer was 
released in 1993. We wanted a game where the player had to chase the ball and use 
skill to keep it. We certainly didn’t want to replicate a televised game. We preferred 
to make players feel like they were on the pitch rather than an uninvolved member 
of a TV audience.” 

Sensible Soccer initially appeared on the Amiga and the Atari ST in June 1992 
before later being converted to the PC, Mega Drive, and other platforms. It focused 


We concentrated 
on the actual 
gameplay when 
we created 
Sensible Soccer 
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mostly on European club football, adding a few international teams. Some versions 
had made-up player names and included some fictitious custom football teams. The 
game had great pace and required a high level of skill. Sensible Soccer's beauty came 
from within. 

Creating the beautiful game 

The first thing Jon and his team did when creating the game was look at perfecting 
the controls. They thought about how people would play the game and the type of 
controller they would use, before starting to think about the best way for the action 
to evolve. At the time of development, most home platforms used eight-directional 
joysticks (left, right, up, down, and diagonals) with a single fire button. 

“Every game, whether football or otherwise, should be designed around the 
hardware itself, so that’s what we did well with Sensible Soccer ,” explains Jon. “We 
designed the controls around the limitations of the Commodore Amiga hardware, 
which was that eight-direction joystick and a single button. All the best games are 
designed that way and it helped to get things right.” 

With the controls in place, the developer was then able to deconstruct the 
real-life game of football itself so that it could be recreated in pixellated form. Basing 
the game on an existing sport helped enormously since it provided a set of ready¬ 
made rules, allowing Sensible Software to take a few design short cuts. By working in 
accordance with the sport’s specific objects and established rules, the developer could 
concentrate on the skills needed by players and on the best ways of providing them 
with an adrenaline rush. 

This is why some games have got away with stripping right back. You don’t 
necessarily need leagues, cups, and tournaments, for instance, although they can 
provide a more immersive experience. You don’t really need crowd noise, let alone 
commentary. Red and yellow cards can be done away with, as can over-the-top goal 
celebrations. As long as the ball moves as well as expected and the players can make 
their way reasonably quickly from one end to the next, football can be recreated 
convincingly on screen. The key is to get the behind-the-scenes elements right. 
“There’s plenty of stuff in a game like Sensible Soccer other than what is straight out 
there on the football pitch,” advises Jon. “The whole framework has to be there too, 
taking in the graphics and sound as well as the ball skills and gravity.” 


Learn from the master 

Jon Hare offers some expert advice for making your football game a winner. 

The right mindset: When you play sport, you’re drawing on your whole body. In a football video game, 
you tend to use just your brain and hands. Jon advises getting into the player mindset. 

Keep it simple: Psychologically,you think up and down the pitch when you play football - the goal 
behind you and in front of you. 

Shots count: Always make the goals big enough for shots to have a chance of going in, otherwise 
frustrated gamers will lose the desire to keep playing. 
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Player movement 

The joystick was used to move the players around 
the pitch and to indicate where the ball should travel 
when it was kicked. “The fire button would be tapped 
to pass the ball along the ground and held down 
to do something in the air,” Jon says. These simple 
controls enabled the gamer to perform a large number 
of moves, depending on whether he or she was in 
possession of the ball. With possession of the ball, the 
player could pull back on the joystick or swiftly switch it 
from one direction to another in order to achieve chips, 
volleys, lobs, and headers. There were trick shots and a 
banana shot available too. 

If gamers pushed forward, the sprite in 
possession would dribble the ball. If they pushed in a 
particular direction and tapped the fire button, the ball 
would be passed along the ground. By pressing longer, it would be kicked harder. 
There was a short amount of time following a kick for the gamer to lift and bend 
the ball by quickly moving the joystick. Depending on how it was done, this could 
result in straight or bending kicks: pulling down (i.e. in the opposite direction) quickly 
following a kick would send the ball high up into the air. 

When a player had the ball, it stuck to his feet unless he turned too sharply. 
This was a conscious decision - the other way of doing it is to make the sprite bump 
into the ball repeatedly to edge it around the screen. “If you bounce the ball away 
from the player, the disadvantage is the animation means the player has to gather the 
ball as he turns,” explains Jon. “The problem of bouncing four feet in front of him is 
that when he turns sharp left, the ball will drag with him. The closer it stays to his feet, 
Messi style, the more naturalistic it will look when he physically turns left or right. 
This is counterbalanced by allowing the player to lose the ball if he turns too sharply, 
dependent upon his ball control skill.” 

Off-the-ball mechanics 

If the player was off the ball (i.e. defending) in Sensible Soccer , pressing fire would 
perform a sliding tackle in the direction faced; if the ball was overhead, hitting fire 
would attempt a header. Sensible Software made the game easier for the player by 
keeping the goalkeepers under the control of the computer. That way, the focus could 
remain on the outfield play. 

Jon says the control system off the ball is just as important as when the 
player is in possession. “A good control system off the ball is vital because 50 percent 
of the time you are on the ball and 50 percent of the time you’re not. So you want 
controls that enable the player to get to the ball as quickly as possible and a passing 
system that intelligently selects where the player is intending to play the ball.” 

Tackling is also vital when a player does not have 
the ball and this requires a routine. To make tackling work 
well, when the players that run towards the ball are within a 
certain number of degrees from alignment with it, they are 
automatically aimed directly at the ball. “Fifteen degrees is 


4 The Sensible 
team enjoying 
a kickabout to 
promote the 
launch of SWOS 


Top tips 

•Think about overall 
presentation.Jon Hare 
says game controls 
and the actual game 
are only a part of a 
professional package. 

• Consider the different 
roles of players: do 
you want give your 
strikers different 
attributes than 
the defenders? 
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The objectives 

Short term: Work on the controls so that each player is able to move around the pitch, kick and tackle, 
and score. 

Medium term: Add in the goal scoring system, the amount of time you want there to be for each half, 
and the additional rules of the game. 

Long term: To absorb players into the game, there needs to be something to pull them back in. 

Adding cups and leagues would do the trick. 


the number we used,” Jon reveals. “This means a slide tackle will be more accurate 
because the animation will be focused in the direction of the ball. The player slide- 
tackling should be slide-tackling to a projected position of the ball, possibly two 
or three frames ahead of where it currently is and not directly now. So it will be 
projecting in two or three frames time that the ball will be in this position, so the 
players slide-tackles towards that position. Then there are other calculations. If you 
tackle in front, it’s a good clean tackle and the player wins the ball. If it’s behind, the 
player concedes a foul, maybe even gets a yellow or red card. And from the side, it 
depends on the relative tackling and ball control skills of the players involved.” 

Ball in play 

The Sensible Soccer development team needed to figure out what happened when the 
ball was being played, and build physics and graphics accordingly. “When the ball 
leaves the foot of a player, the programmer has to think about drawing a shadow 
underneath the ball,” says Jon. “He or she also has to take into account the way the 
animation of the player is working and this basically operates on three levels: the 
floor height, which is your dribbling, kicking, slide tackles, and so on; the waist height, 
which is volleys and diving headers; and head height, which is mainly headers. So 
when the ball leaves the foot of a player, you take into account the arc of the ball. I 
guess it is harder to keep the ball down when it starts off already off the floor, but that 
is worked into the physics and gravity systems, so the main thing is the animations.” 

All of this helped to make Sensible Soccer as realistic as possible. Even though 
the sprites in the game were tiny, they ran smoothly and gamers 
could see tackles being carried out in an obvious way, with decent 
renditions of the players on the pitch. Many of the teams had 
made-up names because the official licences would have proven 
too expensive (try getting licensing deals for the likes of Manchester 
United, Barcelona, or Bayern Munich today and you’d certainly 
pay through the nose), but the Sensible Soccer developers had to 
consider the colours of the kit the players wore. 

“The main thing we had to think about is that the players 
were against a green pitch, so it was about avoiding what colours 
worked badly,” says Jon. “Pretty much the worst colour is green, 
understandably, but certain shades of yellow and maybe orange 
didn’t work so well either. It made it harder to, say, recreate the 
Dutch national team or Blackpool FC, but most of the others 
worked fine.” 


5 The console 
conversions 
feature 
this match 
intro screen 

6 The top-down 
view is ideal 
for seeing 
where your 
team-mates are 

7 Scoring goals 
requires skilful 
ball control 
and a good 
passing game 
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Top-down or side-on? 

Sensible Soccer was viewed from the top down, but this wasn’t to make it easier for the developers 
to code. According to Jon Hare, neither the top-down view or the side-on view is any more difficult 
than the other to program.The Sensible Software team decided on a top-down view because Jon 
believes it makes for a more realistic game when it is being played.“A top-down view gives you more 
of the viewpoint from a football player, and the side-on view gives you more of the viewpoint from 
a football spectator in a stadium or on television. That’s why Sensible Soccer feels like a footballer’s 
football game: because you feel like you’re playing it.” 


A good frame rate kept the action flowing and an absence of too much on¬ 
screen clutter gave gamers the best possible view of the pitch and the positions of 
the players. Sensible Software decided not to bother having the score constantly 
displayed on the screen - it only appeared when a goal was scored or the ball left 
the pitch. “The score system for football was dead simple, though,” says Jon. “Who 
scored the most goals won, and that’s the only score system we needed. It can get 
complicated if you have figures evaluating players — so, a system based on how 
many tackles and passes and shots are accurately 
performed - but scoring is just 1-0, 2-0 and so 
on, and easily implemented.” 

It was easy to add flourishes like cards 
and substitutions. “Adding red and yellow cards 
was simple,” he says. “They were created as part 
of the taclding system.” The team wrote code 
which worked out the nature of the taclde and 
the opposition player’s movement and position 
to detect whether there was foul play. “In Sensible 
Soccer , you only got a red or yellow card if you 
taclded from behind,” Jon adds. 

Substitutions were activated by using 
either the joystick or the keyboard (Sensible 
Software was unafraid of making use of the keyboard to add greater control over 
non-action elements of the game). Pressing the up or down arrow key called up 
the bench, depending on the team, and the player could then select the substitute, 
indicating who was coming on and who was going off. “Players could call it up at any 
time when the ball was out of play,” says Jon. “This was quite simple to do.” Gamers 
were also able to save their games at any point, which avoided having to complete a 
tournament or league in one sitting. 

Things became more complex from a development point of view when 
Sensible Software created a slightly improved version in 1993, called the Sensible 
Soccer International Edition. It also released a substantially more complex sequel, Sensible 
World of Soccer , in 1994, adding many more menus, 1400 teams, and 23,000 players 
from all over the world, along with a management section, taldng advantage of 
the 1990s popularity of football management games like Championship Manager. “A 
football game has a lot of menus, league systems, team selections and so on, which 
are vitally important for more advanced titles,” says Jon, whose own development 


In Sensible Soccer, 
you only got a red 
or yellow card 
if you tackled 
from behind 
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team was having lots of fun. As well as putting together a serious recreation of world 
football, they believed that an entertaining game should have off-beat elements, 
and kept the fun up by making it possible to compete in the Turkey Tournament 
or Booby League and see European Cities go up against Great Wars. They even 
included West Germany, even though the team ceased to exist in 1990 following 
German reunification. 

Jon hasn’t stopped developing football games, and this kind of philosophy is 
being carried over into his latest game, Sociable Soccer. It retains all of the fast, slick 
playability of Jon’s classic football games, but this time using cutting-edge technology, 
featuring online and offline play, 1000 teams from all over the world, 31 collectable 
and upgradable player cards, and support for all current virtual reality systems. 

In 2006, Sensible World of Soccer was honoured by Stanford University in 
California as one of the ten most influential computer games of all time, alongside 
such greats as Spacewar /, Super Mario Bros. 3 , and Tetris. Sociable Soccer looks set to reboot 
a 1990s classic into the modern era. 
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Coding Today 

Substitute 



O ur final game, Substitute Soccer , is 
inspired by top-down-view football 
classics such as Kick Off 2 and Sensible 
Soccer. It features both one- and two- 
player modes, as well as three difficulty 
settings. Each team has seven players 
— and as the pitch is larger than the game window, the 
viewport scrolls on both the X and Y axes. 

As before, we’ll start by looking at the classes which 
contain the bulk of the game’s code. Game, Ball, Player, 
and Goal are all pretty self-explanatory — although we 
should note that the Player class is used by each of the 14 
football players on the pitch, only one or two (depending 
on the game mode) of which are controlled by a human 
player at any one time. Whereas in, for example, Myriapod , 
an instance of the Player class is the manifestation of the 
human player in the game, in this game it makes more 
sense to think in terms of a particular team corresponding 


Download the code 

Download the fully commented Substitute Soccer game code, along 
with all the graphics and sounds, from wfmag.cc/CTCl-soccer 
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to a human player, rather than a specific player on the pitch. Difficulty is used to 
store and refer to a number of parameters which are chosen based on the difficulty 
level. Controls deals with control inputs (arrow keys and SPACE for player 1, WSAD 
and left SHIFT for player 2). Team stores an instance of the Controls class, which 
determines the controls for the relevant player — computer-controlled teams use 
the value None here. The Team class also keeps track of the active_control_player 
- the player on the pitch currently being controlled by a human, indicated by an 
arrow over their head. When they don’t have the ball, a human player can switch the 
active_control_player using the same key they use to kick the ball. 

You may remember that Burner had a class named MyActor, which inherited 
from Pygame Zero’s Actor class, and was the base class of all objects in the game. 
Amongst other things, MyActor made sure that objects were displayed at the correct 
position on the screen, based on the scrolling of the level. This game also has a 
MyActor class - and while part of its job is to deal with scrolling, it has another 
important purpose. In Boing!, we introduced the concept of vectors. That game’s Ball 
class defined a pair of attributes — dx and dy - which together formed a unit vector, 
indicating the ball’s current direction of travel. In Soccer , we’ve made use of Pygame’s 
Vector2 class. Instances of this class store the X and Y components of a vector, and 
the class defines a number of useful methods such as length and normalize, and 
allows us to subtract one vector from another - 
which is necessary when we want to work out the 
position of an object in relation to another, or the 
distance between two objects. The MyActor class 
defines the attribute vpos, which stores an object’s 
position using a Vector2. Having made the 
decision to store positions in this way, it’s vital to 
remember to always access or change an object’s 
position via vpos, and not via Pygame Zero’s 
usual methods of accessing Actor positions, such 
as pos or x and y. The only time we set those is 
when it’s time to actually draw the object on the 
screen. We also need to be careful when we want 
to copy the contents of one Vector2 to another. 

As with any class in Python, instances of Vector2 
are reference types. Therefore, copying should be 
done like this - v2 = Vector2(v1) - rather than 
this: v2 = vl. The latter means that the variable 
v2 will refer to the same object as vl, so changing 
one will change the other. 

The Game class creates and maintains 
objects for the teams, players, goals, and ball. Its 
reset method is called at the start of the game 
and after each goal - it recreates the players, ball, 
and goals, and decides the initial positions of 
the players on the pitch. Amongst other things, 

Game.update detects goals being scored and 
assigns players to mark one another (including 


Visualisation quest 

With so many computer-controlled players running around 
once, it can be hard to verify that the Al code is doing what 
it’s supposed to be doing - especially given that players 
can change roles multiple times within the space of a few 
seconds. One moment a player might be acting as a goalie, 
then he might be one of the ‘lead’ players trying to tackle 
the ball owner, then he might be marking a player on the 
opposite team. One way to help to confirm everything is 
working as it should is to use debug visualisations. Near 
the top of the code you’ll see a number of constants such 
as DEBUG_SHOW_TARGETS. When set to True, Game. d raw 
displays a line from each player, showing the position 
they’re currently running towards. Debug visualisations can 
also be useful for learning how a game works. Try turning 
on each one - preferably one at a time. 
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assigning a goalie on hard difficulty). If a team has the ball, it also chooses either one 
or two (depending on difficulty level) ‘lead’ players from the other team, who will try 
to intercept the ball. 

As with the previous games, the final part of the code uses a simple state 
machine system to process interactions with the main menu, and trigger updating and 
drawing of the current Game instance. There are also a number of helper functions to 
do with ball physics, targeting, and angles. In this game, the numbers 0 to 7 are used 
for angles, with 0 representing up, 1 up and right, 2 right, and so on. Hence we have 
our own custom sine and cosine functions which work with those angles, as opposed 
to degrees and radians. 


Counting the cost 

When a computer player has the ball, there are two decisions it has to make each frame - which 
direction to run in, and whether to kick the ball.These decisions are made with the help of the cost 
function. Given a position on the pitch and a team number, it calculates the number representing 
how good or bad it would be for the ball to move to that position - the lower the better.The cost 
value is calculated based on the distance to our own goal (further away is better), the proximity of 
the position to players on the opposing team, a quadratic equation (don’t panic too much!) causing 
the player to favour the centre of the pitch and their opponents goal, and a ‘handicap’ value. 

The cost function is called in two places. First, when a player with the ball is deciding where 
to run, cost is called five times, each time being passed a position indicating where the player 
would be if they were to move slightly forward in a particular direction - the five directions being 
straight ahead, left or right 45°,and left or right 90°. cost's optional third parameter, handicap, 
is used to slightly discourage the player from making turns - this ensures that the player doesn’t 
exhibit unrealistic behaviour such as repeatedly turning left and right within the space of a fraction 
of a second, cost is also called when a player is deciding whether to pass the ball to a team-mate. 

A piece of code in Ball. update tries to find a suitable player to pass to, but the pass only goes 
ahead if the cost value for the target player’s location is less than the cost value for the current 
player’s location. 
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I am very intelligent 

The Al in the previous games has mostly been very straightforward.The bat in Boing! moves along 
a single axis, obeying just two rules - stay near the centre when the ball is far away; as the ball 
gets nearer, increasingly try to follow its movement. In Cavern, the robots move forward, randomly 
change direction, and randomly decide to shoot - with a higher probability if the player is at the 
same height as the robot. Gunner doesn’t really have Al, and in Myriapod the segments choose 
their next cell based on a series of rules, with higher-priority rules taking precedence over others. 
Although the games are very different, Soccer's Al is closest to that of Myriapod. Each frame, a 
computer-controlled player decides their next action based on a series of conditions.The first is 
whether anyone currently has the ball. If so, it must be owned by either that player, someone on 
their team, or someone on the opposite team. Each scenario has its own corresponding behaviour. 
Alternatively, it might be that no-one has the ball.This could be because kick-off is about to take 

place, in which case no players are allowed to 
move other than the player who is about to 
take the kick-off. Otherwise, all players who 
currently considered ‘active’ (i.e. are within 400 
pixels of the ball on the Y axis) will attempt to 
intercept the ball by looking at its trajectory 
and calculating where to run to have the best 
chance of obtaining it. 



Challenges 


■ Display a different message from the usual ‘GOAL!’ if an own goal is scored. 


■ Try enlarging the game window so you can see more of the pitch at once. Notice how certain aspects 
of the user interface do not display correctly after this change. How would you fix this? 


■ The game includes code allowing players to mark players on the opposing team - however, this is 
currently only enabled for computer-controlled teams.Try enabling this marking behaviour for human 
teams. Consider how this affects the gameplay and whether you feel the game is better or worse 
having made this change. 


■ Give each player a name. Display this above their head, using Pygame Zero’s screen, draw, text 
method. You could also generate stats for each player,altering their speed in different circumstances 
- e.g. when running with or without the ball. 


■ Simulate a full-length match, including swapping ends at half-time. Display a timer on the screen 
indicating the number of minutes into the match.The timer could advance at, for example, one 
minute of game time for every five seconds of real time. Make sure that the timer is stopped during 
the kick-off phase - otherwise a player could run down the clock by refusing to kick-off! 
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How to run the game 

Open the soccer.py file in a Python editor, such as IDLE,and select Run > Run Module. 
For more details, see the ‘Setting up’section on page 186. 


Download the code wfmag.cc/CrCl-soccer 


001. import pgzero, pgzrun, pygame 

002. import math, sys, random 

003. from enum import Enum 

004. from pygame.math import Vector2 

005. 

006. if sys.version_info < (3,5): 

007. print("This game requires at least version 3.5 of Python. Please download 

008. "it from www.python.org") 

009. sys.exit() 

010. 

011. pgzero_version = [int(s) if s. isnumeric() else s for s in pgzero._version_. 

012. split( 1 .' )] 

013. if pgzero_version < [1,2]: 

014. print("This game requires at least version 1.2 of Pygame Zero. You are" 

015. "using version {pgzero. version }. Please upgrade using the command 

016. "'pip install —upgrade pgzero'") 

017. sys.exit() 

018. 

019. WIDTH = 800 

020. HEIGHT = 480 

021 . TITLE = "Substitute Soccer" 

022. 

023. HALF_WINDOW_W = WIDTH / 2 

024. 

025. LEVEL.W = 1000 

026. LEVEL.H = 1400 

027. HALF_LEVEL_W = LEVEL.W // 2 

028. HALF_LEVEL_H = LEVEL.H // 2 

029. 

030. HALF_PITCH_W = 442 

031 . HALF_PITCH_H = 622 

032. 

033. GOAL.WIDTH = 186 

034. GOAL.DEPTH = 20 

035. HALF_GOAL_W = GOAL_WIDTH // 2 

036. 

037. PITCH_BOUNDS_X = (HALF_LEVEL_W - HALF_PITCH_W, HALF_LEVEL_W + HALF_PITCH_W) 

038. PITCH_BOUNDS_Y = (HALF_LEVEL_H - HALF_PITCH_H, HALF_LEVEL_H + HALF_PITCH_H) 

039. 
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040. G0AL_B0UNDS_X = (HALF_LEVEL_W - HALF_GOAL_W, HALF_LEVEL_W + HALF_GOAL_W) 

041. G0AL_B0UNDS_Y = (HALF_LEVEL_H - HALF_PITCH_H - GOAL.DEPTH, 

042. HALF_LEVEL_H + HALF_PITCH_H + GOAL.DEPTH) 

043. 

044. PITCH.RECT = pygame.rect.Rect(PITCH_BOUNDS_X[0], PITCH_BOUNDS_Y[0], 

045. HALF_PITCH_W * 2, HALF_PITCH_H * 2) 

046. GOAL_0_RECT = pygame.rect. Rect (GOAL_BOUNDS_X[0], GOAL_BOUNDS_Y[0], 

047. GOAL.WIDTH, GOAL.DEPTH) 

048. G0AL_1_RECT = pygame.rect. Rect (GOAL_BOUNDS_X[0], G0AL_B0UNDS_Y[1] - GOAL.DEPTH, 
049. GOAL.WIDTH, GOAL.DEPTH) 

050. 

051. AI_MIN_X = 78 

052. AI_MAX_X = LEVEL_W - 78 

053. AI_MIN_Y = 98 

054. AI_MAX_Y = LEVEL.H - 98 

055. 

056. PLAYER_START_POS = [(350, 550), (650, 450), (200, 850), (500, 750), (800, 950), 
057. (350, 1250), (650, 1150)] 

058. 

059. LEAD_DISTANCE_1 = 10 

060. LEAD_DISTANCE_2 = 50 

061. 

062. DRIBBLE_DIST_X, DRIBBLE_DIST_Y = 18, 16 

063. 

064. PLAYER_DEFAULT_SPEED = 2 

065. CPU_PLAYER_WITH_BALL_BASE_SPEED =2.6 

066. PLAYER_INTERCEPT_BALL_SPEED =2.75 

067. LEAD_PLAYER_BASE_SPEED =2.9 

068. HUMAN_PLAYER_WITH_BALL_SPEED = 3 

069. HUMAN_PLAYER_WITHOUT_BALL_SPEED =3.3 

070. 

071. DEBUG_SHOW_LEADS = False 

072. DEBUG_SHOW_TARGETS = False 

073. DEBUG_SHOW_PEERS = False 

074. DEBUG_SHOW_SHOOT_TARGET = False 

075. DEBUG_SHOW_COSTS = False 

076. 

077. class Difficulty: 

078. def _init_ (self, goalie_enabled , second_lead_enabled, speed_boost, 

079. holdoff_timer) : 

080. self .goalie_enabled = goalie_enabled 

081. self .second_lead_enabled = second_lead_enabled 

082. self .speed_boost = speed_boost 

083. self .holdoff_timer = holdoff_timer 

084. 

085. DIFFICULTY = [Difficulty (False , False, 0, 120), Diff iculty(False, True, 0.1, 90), 
086. Diff iculty(True, True, 0.2, 60)] 
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087. 
088. 
089. 
090. 
091 . 
092. 
093. 
094. 
095. 
096. 
097. 
098. 
099. 
100 . 
101 . 
102 . 

103. 

104. 

105. 

106. 

107. 

108. 

109. 

110 . 
Ill . 
112 . 

113. 

114. 

115. 

116. 

117. 

118. 

119. 

120 . 
121 . 
122 . 

123. 

124. 

125. 

126. 

127. 

128. 

129. 

130. 
131 . 

132. 

133. 


def sin(x): 

return math.sin(x*math.pi/4) 

def cos(x): 

return sin(x+2) 

def vec_to_angle(vec) : 

return int(4 * math. atan2(vec .x, -vec.y) / math.pi + 8.5) % 8 

def angle_to_vec(angle) : 

return Vector2(sin(angle) , -cos(angle)) 

def dist_key(pos) : 

return lambda p: (p.vpos - pos). length() 

def safe_normalise(vec) : 
length = vec.lengthQ 
if length == 0: 

return Vector2(0, 0) , 0 
else: 

return vec. normalize() , length 
class MyActor(Actor) : 

def _init_ (self, img, x=0, y=0, anchor=None) : 

super() . __init_ (img, (0, 0), anchor=anchor) 
self.vpos = Vector2(x, y) 

def draw(self, offset_x, offset_y): 

self. pos = (self.vpos.x - offset_x, self.vpos.y - offset_y) 

super().draw() 

KICK.STRENGTH =11.5 
DRAG =0.98 

def ball_physics(pos, vel, bounds): 
pos += vel 

if pos < bounds[0] or pos > bounds[1]: 
pos, vel = pos - vel, -vel 

return pos, vel * DRAG 

def steps(distance) : 

steps, vel = 0, KICK.STRENGTH 

while distance > 0 and vel > 0.25: 
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134. 

135. 

136. 

137. 

138. 

139. 

140. 
141 . 

142. 

143. 

144. 

145. 

146. 

147. 

148. 

149. 

150. 
151 . 

152. 

153. 

154. 

155. 

156. 

157. 

158. 

159. 

160. 
161 . 
162. 

163. 

164. 

165. 

166. 

167. 

168. 

169. 

170. 
171 . 

172. 

173. 

174. 

175. 

176. 

177. 

178. 

179. 

180. 


distance, steps, vel = distance - vel, steps + 1, vel * DRAG 

return steps 

class Goal(MyActor) : 

def _init_ (self, team): 

x = HALF_LEVEL_W 

y = 0 if team == 0 else LEVEL_H 

superQ. _init_ ("goal" + str(team), x, y) 

self. team = team 

def active(self ): 

return abs(game .ball.vpos.y - self.vpos.y) < 500 

def targetable(target , source): 

v0, d0 = safe_normalise(target .vpos - source.vpos) 

if not game.teams[source.team]. human() : 

for p in game.players: 

vl, dl = safe_normalise(p. vpos - source.vpos) 

if p.team != target.team and dl > 0 and dl < d0 and v0*v1 > 0.8: 
return False 

return target.team == source.team and d0 > 0 and d0 < 300 and \ 

v0 * angle_to_vec(source.dir) > 0.8 


def avg(a, b): 

return b if abs(b-a) < 1 else (a+b)/2 

def on_pitch(x, y): 

return PITCFLRECT. collidepoint(x, y) \ 

or GOAL_0_RECT. collidepoint(x,y) \ 
or G0AL_1_RECT. collidepoint(x, y) 

class Ball(MyActor) : 
def _init_ (self): 

superQ . _init_ ("ball" , HALF_LEVEL_W, HALF_LEVEL_H) 

self. vel = Vector2(0, 0) 

self. owner = None 
self. timer = 0 

self, shadow = MyActorQballs" ) 
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181 . 
182. 

183. 

184. 

185. 

186. 

187. 

188. 

189. 

190. 
191 . 

192. 

193. 

194. 

195. 

196. 

197. 

198. 

199. 

200 . 
201 . 
202 . 

203. 

204. 

205. 

206. 

207. 

208. 

209. 

210 . 
211 . 
212 . 

213. 

214. 

215. 

216. 

217. 

218. 

219. 

220 . 
221 . 
222 . 

223. 

224. 

225. 

226. 
227. 


def collide(self , p): 

return p.timer < 0 and (p.vpos - self .vpos). length() <= DRIBBLE_DIST_X 

def update(self ): 
self. timer -= 1 

if self. owner: 

new_x = avg(self .vpos.x, self .owner.vpos.x + DRIBBLE_DIST_X * 
sin (self .owner.dir)) 

new_y = avg(self .vpos.y, self .owner.vpos.y - DRIBBLE_DIST_Y * 
cos (self .owner.dir)) 

if on_pitch(new_x, new_y): 

self. vpos = Vector2(new_x, new_y) 
else: 

self .owner.timer = 60 

self.vel = angle_to_vec(self. owner.dir) * 3 
self. owner = None 

else: 

if abs(self .vpos.y - HALF_LEVEL_H) > HALF_PITCH_H: 

bounds.x = G0AL_B0UNDS_X 
else: 

bounds.x = PITCH_BOUNDS_X 

if abs(self .vpos.x - HALF_LEVEL_W) < HALF_GOAL_W: 

bounds.y = G0AL_B0UNDS_Y 
else: 

bounds.y = PITCH_BOUNDS_Y 

self. vpos.x, self.vel.x = ball_physics(self. vpos.x, self.vel.x, bounds_x) 
self. vpos.y, self.vel.y = ball_physics(self. vpos.y, self.vel.y, bounds_y) 

self .shadow.vpos = Vector2(self .vpos) 

for target in game.players: 

if (not self. owner or self .owner.team != target.team) and \ 
self . coll ide( target): 
if self. owner: 

self .owner.timer = 60 

self. timer = game.difficulty.holdoff_timer 

game.teams[target.team].active_control_player = self. owner = target 
if self. owner: 

team = game.teams [self .owner.team] 
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228. 

229. 

230. 
231 . 

232. 

233. 

234. 

235. 

236. 

237. 

238. 

239. 

240. 
241 . 

242. 

243. 

244. 

245. 

246. 

247. 

248. 

249. 

250. 
251 . 

252. 

253. 

254. 

255. 

256. 

257. 

258. 

259. 

260. 
261 . 
262. 

263. 

264. 

265. 

266. 

267. 

268. 

269. 

270. 
271 . 

272. 

273. 

274. 


targetable_players = [p for p in game.players + game.goals if p.team == 
self .owner.team and targetable(p, self. owner)] 

if len(targetable_players) > 0: 

target = min(targetable_players, key=dist_key(self.owner.vpos)) 
game.debug_shoot_target = target.vpos 
else: 

target = None 
if team. human() : 

do_shoot = team.controls. shoot() 
else: 

do_shoot = self. timer <= 0 and target and cost(target. vpos, 

self .owner.team) < cost(self.owner.vpos, self .owner.team) 

if do_shoot: 

game. play_sound("kick" , 4) 

if target: 
r = 0 

iterations = 8 if team.human() and isinstance(target , Player) else 1 

for i in range(iterations) : 

t = target.vpos + angle_to_vec(self. owner.dir) * r 
vec, length = safe_normalise(t - self. vpos) 
r = HUMAN_PLAYER_WITHOUT_BALL_SPEED * steps(length) 

else: 

vec = angle_to_vec(self. owner.dir) 

target = min([p for p in game.players if p.team == 

self .owner.team], key=dist_key(self.vpos + (vec * 250))) 

if isinstance(target , Player): 

game. teams[self. owner.team].active_control_player = target 

self .owner.timer = 10 

self .vel = vec * KICK.STRENGTH 

self. owner = None 

def allow_movement(x, y): 

if abs(x - HALF_LEVEL_W) > HALF_LEVEL_W: 
return False 

elif abs(x - HALF_LEVEL_W) < HALF_GOAL_W + 20: 
return abs(y - HALF_LEVEL_H) < HALF_PITCH_H 

else: 

return abs(y - HALF_LEVEL_H) < HALF_LEVEL_H 
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275. 

276. def cost(pos, team, handicap=0): 

277. own_goal_pos = Vector2(HALF_LEVEL_W, 78 if team == 1 else LEVEL.H - 78) 

278. inverse_own_goal_distance = 3500 / (pos - own_goal_pos). length() 

279. 

280. result = inverse_own_goal_distance \ 

281. + sum([4000 / max(24, (p.vpos - pos). length()) 

282. for p in game.players if p.team != team]) + ((pos.x 

283. - HALF_LEVEL_W)**2 / 200 - pos.y * (4 * team - 2)) + handicap 

284. 

285. return result, pos 

286. 

287. class Player(MyActor) : 

288. ANCHOR = (25,37) 

289. 

290. def init (self, x, y, team): 

291 . kickoff_y = (y / 2) + 550 - (team * 400) 

292. super(). init ("blank", x, kickoff_y, Player.ANCHOR) 

293. 

294. self. home = Vector2(x, y) 

295. self. team = team 

296. self. dir = 0 

297. self .anim_frame = -1 

298. self. timer = 0 

299. self. shadow = MyActor("blank" , 0, 0, Player .ANCHOR) 

300. self .debug_target = Vector2(0, 0) 

301 . 

302. def active(self ): 

303. return abs(game.ball.vpos.y - self. home.y) < 400 

304. 

305. def update(self ): 

306. self. timer -= 1 

307. target = Vector2(self .home) 

308. speed = PLAYER_DEFAULT_SPEED 

309. my_team = game.teams [self .team] 

310. pre_kickoff = game.kickoff_player != None 

311. i_am_kickoff_player = self == game.kickoff_player 

312. ball = game.ball 

313. 

314. if self == game. teams[self. team].active_control_player and \ 

315. my_team. human() and (not pre_kickoff or i_am_kickoff_player): 

316. 

317. if ball.owner == self: 

318. speed = HUMAN_PLAYER_WITH_BALL_SPEED 

319. else: 

320. speed = HUMAN_PLAYER_WITHOUT_BALL_SPEED 

321 . 
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322. 

323. 

324. 

325. 

326. 

327. 

328. 

329. 

330. 

331. 

332. 

333. 

334. 

335. 

336. 

337. 

338. 

339. 

340. 

341. 

342. 

343. 

344. 

345. 

346. 

347. 

348. 

349. 

350. 
351 . 

352. 

353. 

354. 

355. 

356. 

357. 

358. 

359. 

360. 

361. 

362. 

363. 

364. 

365. 

366. 

367. 

368. 


target = self.vpos + my_team.controls. move(speed) 

elif ball.owner != None: 
if ball.owner == self: 

costs = [cost(self.vpos + angle_to_vec(self .dir + d) * 3, 

self. team, abs(d)) for d in range(-2, 3)] 

target = min(costs, key=lambda element: element[0]) 
speed = CPU_PLAYER_WITH_BALL_BASE_SPEED + game.difficulty.speed.boost 

elif ball.owner.team == self. team: 
if self .activeQ : 

direction = -1 if self. team == 0 else 1 
target.x = (ball.vpos.x + target.x) / 2 
target.y = (ball.vpos.y + 400 * direction + target.y) / 2 

else: 

if self. lead is not None: 

target = ball.owner.vpos + angle_to_vec(ball .owner.dir) * self. lead 
target.x = max(AI_MIN_X, min(AI_MAX_X, target.x)) 
target.y = max(AI_MIN_Y, min(AI_MAX_Y, target.y)) 

other_team = 1 if self. team == 0 else 1 
speed = LEAD_PLAYER_BASE_SPEED 
if game.teams[other_team]. human() : 

speed += game.difficulty.speed_boost 

elif self .mark. active() : 

if my_team. human() : 

target = Vector2(ball .vpos) 
else: 

vec, length = safe_normalise(ball .vpos - self .mark.vpos) 

if isinstance(self .mark, Goal): 

length = min(150, length) 
else: 

length /= 2 

target = self .mark.vpos + vec * length 

else: 

if (pre_kickoff and i_am_kickoff_player) or (not pre_kickoff and 

self .activeQ) : 

target = Vector2(ball .vpos) 
vel = Vector2(ball .vel) 
frame = 0 

while (target - self .vpos). lengthQ > PLAYER_INTERCEPT_BALL_SPEED * 
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frame + DRIBBLE_DIST_X and vel.lengthQ >0.5: 
target += vel 
vel *= DRAG 
frame += 1 

speed = PLAYER_INTERCEPT_BALL_SPEED 

elif pre_kickoff: 

target.y = self.vpos.y 

vec, distance = safe_normalise(target - self.vpos) 
self .debug_target = Vector2(target) 

if distance > 0: 

distance = min(distance, speed) 

target_dir = vec_to_angle(vec) 

if allow_movement(self .vpos.x + vec.x * distance, self.vpos.y): 
self.vpos.x += vec.x * distance 

if allow_movement(self. vpos.x, self.vpos.y + vec.y * distance): 
self.vpos.y += vec.y * distance 

self .anim_frame = (self .anim_frame + max(distance, 1.5)) % 72 
else: 

target_dir = vec_to_angle(ball. vpos - self.vpos) 

self .anim_frame = -1 

dir_diff = (target_dir - self. dir) 

self. dir = (self. dir + [0, 1, 1, 1, 1, 7, 7, 7][dir_diff % 8]) % 8 

suffix = str(self .dir) + str((int(self.anim_frame) // 18) + 1) # todo 

self. image = "player" + str(self .team) + suffix 
self .shadow.image = "players" + suffix 
self .shadow.vpos = Vector2(self.vpos) 


class Team: 

def _init_ (self, controls): 

self .controls = controls 

self .active_control_player = None 

self. score = 0 

def human(self): 

return self .controls != None 
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class Game: 

def _init_ (self, p1_controls=None, p2_controls=None, difficulty=2) : 

self. teams = [Team(p1_controls), Team(p2_controls)] 
self .difficulty = DIFFICULTY[difficulty] 

try : 

if self .teams[0]. human() : 
music. fadeout(1 ) 
sounds.crowd. play (-1 ) 
sounds. start. playQ 
else: 

music. play ("theme" ) 
sounds.crowd. stop( ) 
except: 
pass 

self .score_timer = 0 
self .scoring_team = 1 
self. reset() 

def reset(self): 
self. players = [] 

random_offset = lambda x: x + random. randint(-32, 32) 
for pos in PLAYER_START_POS: 

self .players. append(Player(random_offset (pos[0]), 
random_offset(pos[1 ]), 0)) 

self .players. append(Player(random_offset(LEVEL_W - pos[0]), 
random_offset(LEVEL_H - pos[1]), 1)) 

for a, b in zip(self. players, self .playersE:: -1 ]): 
a.peer = b 

self. goals = [Goal(i) for i in range(2)] 
self .teams[0].active_control_player = self .players[0] 
self .teams[1].active_control_player = self .players[1 ] 
other_team = 1 if self .scoring_team == 0 else 0 
self .kickoff_player = self .players[other_team] 

self .kickoff_player.vpos = Vector2(HALF_LEVEL_W - 30 + other_team * 60, 

HALF_LEVEL_H) 

self. ball = Ball() 

self .camera_focus = Vector2(self.ball.vpos) 
self .debug_shoot_target = None 

def update(self ): 

self .score_timer -= 1 

if self .score_timer == 0: 
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self. reset() 

elif self .score_timer < 0 and abs(self .ball.vpos.y - 
HALF_LEVEL_H) > HALF_PITCH_H: 
game. play_sound("goal" , 2) 

self .scoring_team = 0 if self .ball.vpos.y < HALF_LEVEL_H else 1 
self . teams[self .scoring_team].score += 1 
self .score_timer = 60 

for b in self .players: 
b.mark = b.peer 
b.lead = None 
b.debug_target = None 

self .debug_shoot_target = None 

if self .ball.owner: 
o = self .ball.owner 
pos, team = o.vpos, o.team 
owners_target_goal = game.goals[team] 
other_team = 1 if team == 0 else 1 

if self .difficulty.goalie_enabled: 

nearest = min([p for p in self. players if p.team != team], 
key = dist_key(owners_target_goal. vpos)) 

o.peer.mark = nearest.mark 
nearest.mark = owners_target_goal 

1 = sorted([p for p in self. players 
if p.team != team 
and p.timer <= 0 

and (not self .teams[other_team]. humanQ or p != 

self .teams[other_team].active_control_player) 
and not isinstance(p.mark, Goal)], 
key = dist_key(pos)) 

a = [p for p in 1 if (p.vpos.y > pos.y if team == 0 

else p.vpos.y < pos.y)] 
b = [p for p in 1 if p not in a] 

N0NE2 = [None] * 2 

zipped = [s for t in zip(a+N0NE2, b+N0NE2) for s in t if s] 

zipped[0].lead = LEAD_DISTANCE_1 
if self .difficulty.second_lead_enabled: 
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zipped[1].lead = LEAD_DISTANCE_2 

self .kickoff_player = None 

for obj in self. players + [self. ball]: 
obj. update() 

owner = self .ball.owner 

for team_num in range(2): 

team_obj = self .teams[team_num] 

if team_obj . humanQ and team_obj . controls. shootQ : 
def dist_key_weighted(p) : 

dist_to_ball = (p.vpos - self .ball.vpos). lengthQ 
goal_dir = (2 * team_num - 1) 

if owner and (p.vpos.y - self .ball.vpos.y) * goal_dir < 0: 

return dist_to_ball / 2 
else: 

return dist_to_ball 

self .teams[team_num].active_control_player = \ 
min([p for p in game.players 

if p.team == team_num], key = dist_key_weighted) 

camera_ball_vec, distance = safe_normalise(self .camera_focus 

- self .ball.vpos) 

if distance > 0: 

self .camera_focus -= camera_ball_vec * min(distance, 8) 
def draw(self): 

offset_x = max(0, min(LEVEL_W - WIDTH, self .camera_focus.x - WIDTH / 2)) 
offset.y = max(0, min(LEVEL_H - HEIGHT, self .camera.focus.y - HEIGHT / 2)) 
offset = Vector2(offset_x, offset_y) 

screen. blit("pitch" , (-offset_x, -offset_y)) 

objects = sorted([self.ball] + self .players, key = lambda obj: obj.y) 
objects = objects + [obj.shadow for obj in objects] 
objects = [self .goals[0]] + objects + [self .goals[1]] 

for obj in objects: 

obj .draw(offset_x, offset_y) 

for t in range(2): 

if self .teams[t]. human() : 

arrow_pos = self .teams[t].active_control_player.vpos - \ 
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offset - Vector2(11, 45) 
screen. blit("arrow" + str(t), arrow_pos) 

if DEBUG_SHOW_LEADS: 

for p in self .players: 

if game.ball.owner and p.lead: 

line_start = game.ball.owner.vpos - offset 
line_end = p.vpos - offset 

pygame.draw. line(screen. surface, (0,0,0), line_start, line_end) 

if DEBUG_SHOW_TARGETS: 
for p in self .players: 

line_start = p.debug_target - offset 
line_end = p.vpos - offset 

pygame.draw. line(screen. surface, (255,0,0), line_start, line_end) 

if DEBUG_SHOW_PEERS: 

for p in self .players: 

line_start = p.peer.vpos - offset 
line_end = p.vpos - offset 

pygame.draw. line(screen. surface, (0,0,255), line_start, line_end) 

if DEBUG_SHOW_SHOOT_TARGET: 

if self .debug_shoot_target and self .ball.owner: 
line_start = self .ball.owner.vpos - offset 
line_end = self .debug_shoot_target - offset 

pygame.draw. line(screen. surface, (255,0,255), line_start, line_end) 

if DEBUG_SHOW_COSTS and self .ball.owner: 
for x in range(0, LEVEL_W, 60) : 

for y in range(0, LEVEL_H, 26): 

c = cost(Vector2(x,y), self .ball.owner.team)[0] 

screen_pos = Vector2(x,y)-offset 

screen_pos = (screen_pos.x,screen_pos.y) 

screen.draw. text("{0: . 0f}" . format (c), center=screen_pos) 

def play_sound(self , name, c): 
if state != State.MENU: 
try: 

getattr(sounds, name+str(random. randint(0, c-1 ))). play() 
except: 
pass 

key_status = {} 

def key_just_pressed(key) : 
result = False 
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prev_status = key_status.get(key, False) 

if not prev_status and keyboard[key]: 

result = True 

key_status[key] = keyboard[key] 
return result 

class Controls: 

def _init_ (self, player_num): 

if player_num == 0: 

self.key_up = keys.UP 
self .key_down = keys.DOWN 
self .key_left = keys.LEFT 
self .key_right = keys.RIGHT 
self .key_shoot = keys.SPACE 

else: 

self.key_up = keys.W 
self .key_down = keys.S 
self .key_left = keys.A 
self .key_right = keys.D 
self .key_shoot = keys.LSHIFT 

def move(self, speed): 

dx, dy = 0, 0 

if keyboard[self .key_left]: 
dx = -1 

elif keyboard[self .key_right]: 
dx = 1 

if keyboard[self .key_up]: 
dy = -1 

elif keyboard[self .key_down]: 
dy = 1 

return Vector2(dx, dy) * speed 
def shoot(self): 

return key_just_pressed(self .key_shoot) 

class State(Enum): 

MENU = 0 
PLAY = 1 
GAME.OVER = 2 

class MenuState(Enum) : 

NUM.PLAYERS = 0 
DIFFICULTY = 1 
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def updateQ: 

global state, game, menu_state, menu_num_players, menu_difficulty 

if state == State.MENU: 

if key_just_pressed(keys. SPACE): 

if menu_state == MenuState.NUM_PLAYERS: 
if menu_num_players == 1 : 

menu_state = MenuState.DIFFICULTY 
else: 

state = State.PLAY 
menu_state = None 

game = Game(Controls(0) , Controls(l)) 

else: 

state = State.PLAY 
menu_state = None 

game = Game(Controls(0) , None, menu_difficulty) 

else: 

selection_change = 0 

if key_just_pressed(keys.DOWN) : 

selection_change = 1 
elif key_just_pressed(keys.UP): 

selection_change = -1 
if selection_change != 0: 
sounds.move. play () 

if menu_state == MenuState.NUM_PLAYERS: 

menu_num_players = 2 if menu_num_players == 1 else 1 
else: 

menu_difficulty = (menu_difficulty + selection_change) % 3 
game. update() 
elif state == State.PLAY: 

if max([team. score for team in game.teams]) == 9 and game.score_timer 
state = State.GAMEJDVER 
else: 

game. update() 

elif state == State.GAMEJDVER: 

if key_just_pressed(keys. SPACE): 
state = State.MENU 
menu_state = MenuState.NUM_PLAYERS 
game = Game() 

def draw(): 
game. drawQ 
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698. if state == State.MENU: 

699. if menu_state == MenuState.NUM_PLAYERS: 

700. image = "menu0" + str(menu_num_players) 

701. else: 

702. image = "menul" + str(menu_diff iculty) 

703. screen. blit(image, (0, 0)) 

704. 

705. elif state == State.PLAY: 

706. screen. blitf'bar", (HALF_WINDOW_W - 176, 0)) 

707. 

708. for i in range(2): 

709. screen. blit("s" + str(game. teamsEi].score), (HALF_WINDOW_W + 7 

710. - 39 * i, 6)) 

711 . 

712. if game.score_timer > 0: 

713. screen. blitC'goal", (HALF_WINDOW_W - 300, HEIGHT / 2 - 88)) 

714. 

715. elif state == State.GAME_0VER: 

716. img = "over" + str(int(game .teams[1].score > game.teams[0].score)) 

717. screen. blit(img, (0, 0)) 

718. 

719. for i in range(2): 

720. img = "1" + str(i) + str(game. teamsEi].score) 

721. screen. blit(img, (HALF_WINDOW_W + 25 - 125 * i, 144)) 

722. 

723. try: 

724. pygame. mixer .quitQ 

725. pygame.mixer. init (441 00, -16, 2, 1024) 

726. except: 

727. pass 

728. 

729. state = State.MENU 

730. menu_state = MenuState.NUM_PLAYERS 

731. menu_num_players = 1 

732. menu_difficulty = 0 

733. 

734. game = GameQ 

735. pgzrun.goQ 
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7 The menu 
screen enables 
the selection of 
number of players 
and one-player 
difficulty level 
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8 The pitch - only 
part of it is shown 
on screen at 
one time 


9 Digits used for 
the team scores 


10 An arrow is used 
to indicate which 
player is currently 
under control 


11 The game-over 
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Setting up 

Learn how to run and edit the 
games in this book by installing 
Python, Pygame Zero, and an IDE 




o run and edit the games in this book, 
you’ll need three things: 

l. The Python interpreter 

This is the software that allows you to 
run programs written in Python. 


2. Pygame Zero 

An add-on package for Python which takes care of a lot 
of the essentials of game development, such as displaying 
graphics and playing sound. 

3. An integrated development environment (IDE) 

Software which includes a code editor and the ability to run 
a program from that editor. It’s possible to get by without 
an IDE, but it’s much more convenient to use one. 


You must have at least version 3.5 of the Python interpreter. 
Note that when a new version of Python is released, it can 
take some time before Pygame Zero becomes compatible 
with it. At the time of writing, the most recent version of 
Python which can be used with Pygame Zero is 3.7.5. 

There are many IDEs available, here we’re going 
to look at three of them — IDLE, Thonny, and PyCharm. 
IDLE is a very simple IDE which comes bundled with 
Python for Windows and Mac, and is installed by default 
on some versions of the Raspberry Pi’s Raspbian operating 
system. Thonny has some additional features although is 
still geared towards beginners. PyCharm is an advanced 
IDE used by professional developers. We recommend 
Thonny or IDLE for beginners, and PyCharm for more 
experienced or confident users. 

Occasionally, errors can occur while trying to get 
everything installed and running - especially on older 
computers. We’re dealing with three separate pieces of 
software (plus the games themselves) which frequently 
change but have to work together. If you experience errors 
while trying to use a particular IDE or version of Python, 
try another IDE or Python version. 
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Windows 


Installing Python 

Windows does not come with Python pre-installed. If you think you may have 
installed Python previously, you can check this by looking for ‘Python’ in the Start 
menu or under ‘Apps and Features’ within Settings. 

If you intend to use Thonny as your IDE, you can skip ahead to the ‘Thonny’ 
section as Python is automatically installed alongside it, and Pygame Zero can be 
installed via Thonny. 

Go to python.org, mouse-over 
Downloads and click on Windows. Do not 
choose the option to directly download the 
latest version. 

Under ‘Stable Releases’, find Python 
3.7.5, then choose to download ‘Windows x86 
executable installer’. (You could alternatively 
choose the x86-64 (64 bit) installer — both 
versions will work fine with our games.) 

Once the download is complete, run the 
program either via your web browser or from 
your Downloads folder. Check the box next to 
‘Add Python 3.7 to PATH’. Then click ‘Install 
now’ to install using the default options. 

It is also possible to install Python via the 
Microsoft Store, but at the time of writing only Python 3.8 is available, which isn’t 
currently compatible with Pygame Zero. If you have any difficulties, full installation 
instructions can be found at wfmag.cc/python-windows. 

Installing Pygame Zero 

If you intend to use PyCharm as your IDE, you can skip ahead to ‘Installing 
PyCharm’, as Pygame Zero can be installed via that software. 

Otherwise, open a Command Prompt or Windows PowerShell window. 
Enter the command python —version to confirm that Python has installed correctly. 
Then type pip3 install pgzero. This will download the Pygame Zero package, and 
other packages it requires. 


Once the download 
is complete, run 
the program via 
your web browser 
or from your 
Downloads folder 
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Mac 


Installing Python 

Although most versions of macOS come with a Python interpreter, it’s version 2.7 
which is not compatible with Pygame Zero. Therefore you need to install a more up- 
to-date version alongside the existing version. 

Go to python.org, mouse-over Downloads and click on Mac OS X. Do not 
choose the option to directly download the latest version. 

Under ‘Stable Releases’, find Python 3.7.5, then choose to download ‘macOS 
64-bit installer’. 

Once the download is complete, run the program either via your web browser 
or from your Downloads folder. Install using the default options. 

Installing Pygame Zero 

If you intend to use PyCharm as your IDE, you can skip ahead to ‘Installing 
PyCharm’, as Pygame Zero can be installed via that software. 

Otherwise, open a Terminal window. Enter the command python3 —version 
to confirm that Python has installed correctly. Then enter pip3 install pgzero. This 
will download the Pygame Zero package, and other packages it requires. 


Raspberry Pi 


The Raspberry Pi’s Raspbian operating system comes with both Python and Pygame 
Zero already installed. We recommend using at least the 'Buster' release of Raspbian 
(released June 2019). Older versions may have poorer performance, or may not have 
the correct version of Python or Pygame Zero. 

Recent versions of Raspbian come withThonny, but do not include IDLE. 
PyCharm can be used on the Raspberry Pi - see the installation instructions for the 
Linux version: wfmag.cc/pycharm-help. 
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IDEs 


IDLE 

IDLE is a simple IDE which is automatically installed alongside Python. You can 
find it under the Python folder within the Start Menu on Windows, or by searching 
for ‘IDLE’. Make sure you use the correct version of IDLE - in our case, the one for 
Python 3.7. 

Once IDLE starts, the first thing you’ll see is a window titled ‘Python 3.7.5 
Shell’. In this window you can type a line of Python code and see it run straight away. 
For example, try entering: 
x = 5 

Y = 3 
x + y 

You can use the File menu to open a Python foe — for example, boing.py. 
You can then run the game by going to the Run menu and choosing Run Module — 
or by pressing F5. If an error occurs, text will be output to the Python shell window. 


Getting the games 

Although you could try typing in the code of the five games presented in this book, this would be a 
lot of work and prone to errors. More importantly, a game can’t be run without its set of image and 
sound files. Each chapter in this book includes a link where you can download all the files needed to 
get a game running. 

Each game can be downloaded from GitHub - a website for hosting projects stored using 
the git version control system. Git and version control are big topics and outside the scope of this 
book, but are well worth learning about. Each game has its own page on GitHub. There are two 
options for downloading a game. The first is to click on ‘Clone or download’ and choose ‘Download 
ZIP’ - this packages all the game’s files into a zip file which can then be downloaded and extracted 
into a folder. The alternative is to download it directly using the git version control system, which 
you can download from git-scm.com. Install it using the default settings. On the game’s GitHub page, 
copy the web address that comes up when ‘Clone or download’ is clicked, and then either use git via 
the command prompt/terminal to download the project - enter git clone followed by the URL 
found by clicking on ‘Clone or download’ on the game’s GitHub page; or download it via the ‘Check 
out from Version Control’ option in PyCharm, if you intend to use that IDE. 

Once you’ve downloaded a game, there are several ways you can run it. On Windows or 
Mac, you can simply double-click on the game’s Python file in File Explorer. On any system, you can 
navigate to a game’s folder in a command prompt/terminal window and type pgzrun game.py 
(replace game.py with the name of the Python file). Or you can run the game via an IDE. 

Two of the games - Bunner and Myriapod - use particularly tall game windows.These 
can have difficulty fitting on the screen if you have a computer with a low screen resolution, or 
sometimes if you’re using display scaling. In Windows 10, you can check to see if display scaling is 
turned on by going to the display settings - the relevant setting is ‘Change the size of text, apps and 
other items'. If it’s above 100%, and you are having difficulty with a game not fitting on the screen, try 
reducing this to 100%. 
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Thonny 

Thonny comes installed with recent versions of the Raspberry Pi’s Raspbian 
operating system. For Windows and Mac computers, you can download and install 
it from thonny.org. By default, Thonny uses a version of Python which comes 
packaged with it. If you’ve already downloaded Python separately and installed 
Pygame Zero, you can choose to use our version by going to the Run menu, clicking 
‘Select interpreter’, changing the selected option to ‘Alternative Python 3 interpreter 
or virtual environment’, and then selecting the desired interpreter from the second 
drop-down list. 

You can install Pygame Zero from within Thonny, by going to the Tools menu 
and selecting ‘Manage packages’. In the text box, type ‘pgzero’ (without quotes) and 
then click the button to the right. Then click ‘Install’. 

You can use the File menu to open a Python hie - for example, boing.py. 
You can then run the game by selecting the ‘Run current script’ button, or by pressing 
F5. If an error occurs, the details will be output to the Shell area at the bottom of 
the screen. 

Do not enable ‘Pygame Zero mode’ in the Run menu - this is only needed if 
the line pgzrun .go() is not present at the end of the code. 

Thonny includes a debugger which allows you to step through the code one 
line at a time and see how the variables change. However, we have had difficulty 
getting this to work properly and at a decent frame rate when running our games, 
whereas the debugger in PyCharm works much more reliably. 

PyCharm 

PyCharm is a powerful IDE 
with dozens of features. 

One of most useful is code 
completion, where the IDE 
tries to predict what you’re 
going to type based on variable 
and function names, or class 
members. When PyCharm 
shows a list of suggestions, 
you can press TAB to accept 
the currently selected item. 

Another important feature is 
the debugger, which is very 
useful when you’re trying to 
work out why a piece of code 
isn’t working as expected. 

You can download 
PyCharm fromjetbrains.com/pycharm. Make sure you 
get the Community version. Once it’s installed, run it and 
choose the default options. You should end up on a screen 1 PyCharm 

which gives you the option of creating a new project, opening is a more ^ ^ 
an existing project, or checking out from version control. If you | DE w j t h a handy 
haven’t already downloaded the games, the most convenient debugger tool 
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option is to choose ‘Check out from Version Control’ - the 
address to enter in the URL text box is the one that can be 
found by clicking on ‘Clone or download’ on the game’s 
GitHub page — see ‘Getting the games’. If you have already 

downloaded a game, you can select ‘Open’ and choose the folder where you extracted 
the zip hie. Make sure you select the folder which directly contains the game’s hies, 
not a folder which contains another subfolder of the same name, as can happen 
depending on how you unzipped the hies. 

The following instructions will assume you’re trying to run the game Boing!. 

Once the project has loaded, look for the ‘Project’ area near the top left of 
the window. Below the word Project, you should 
see the name of the folder, e.g. boing, with an 
arrow to the left. Click on the arrow to expand 
the folder. You should then see a list of hies and 
folders, one of which will be the game’s Python 
hie — e.g. boing.py. Double-click this to load it. 

If you haven’t yet installed Pygame 
Zero, or you’re not sure if you have the latest 
version, go to the File menu and select Settings. 

Expand ‘Project: boing’ and select ‘Project 
interpreter’. Here you can choose which Python 
interpreter your project will use, and which 
external packages are available. If Pygame Zero 
is installed, you will see ‘pgzero’ in the list of 

packages, and its version number should be displayed alongside it. If it’s there but the 
version number is less than 1.2, select pgzero and click the upward-pointing arrow at 
the right-hand side of the window. If pgzero is not present, click the plus icon near 
the top right of window. Type ‘pgzero’ into the search box and click ‘Install Package’. 
Wait for it to install, then close the window and click OK to close the settings window. 


You can choose which 
Python interpreter 
your project will use, 
and which packages 
are available 
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To run the game, right-click on the background of 
the code area (the main part of the window) and choose ‘Run 
‘boing’ \ If the option is greyed out, this is most likely because 
PyCharm is running some processes in the background which 
need to finish - wait until these are done (see the notification 
at the bottom of the screen) and then try again. 

You can run the game in debug mode by choosing ‘Debug ‘boing’ \ Running 
under the debugger can result in a worse frame rate, but provides a number of 
benefits. If an unhandled exception (a type of error which causes the program to stop) 
occurs, normally all you’ll get is a text printout showing the details of the exception 
(at the bottom of the printout) and the call stack, which indicates the function and 
line number where the error occurred and the functions which called that function. 
In debug mode, an unhandled exception causes the program to pause — you can then 
use the debugger to see where the error occurred, and view the current contents 
of the variables and call stack. You can also manually break into the debugger by 
adding a breakpoint - click in the grey area to the right of a line number. You should 
see a red circle appear. When you run in debug mode, PyCharm will break into the 
debugger just before that line of code is about run. Now you can view the variables 
and call stack as before, but you can also cause the code to run one line at a time by 
using commands such as Step Over and Step Into (via the Run menu or buttons in 
the Debug window). 


3 Running under the 
debugger helps 
you to pinpoint 
errors in the code 
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Talking graphics with 

Dan Malone 


Today, we explore vast and beautiful 
game worlds without restriction. But how 
did graphic artists in gaming’s early days 
replicate environments and characters 
with Limited technology? 


194 





I n the early days of gaming, graphics were everything. Players would 
gush about the cutting-edge graphics of the many coin-operated 
machines vying for their attention in arcades up and down the country 
Certain games would push the visual boundaries of their home 
computers and consoles, and the screenshots on the back of game 
boxes were immensely important to players looking for something they 
could show off to their friends. 

Graphical innovations formed the battle lines between machines as 
playground chatter turned to war over which computer was better. They spawned 
terms such as ‘colour clash 5 , particularly on the ZX Spectrum. They also had 
players reaming off numbers: 27 possible colours on an Amstrad CPC versus 4096 
on a Commodore Amiga... Meanwhile, magazine reviewers dished out marks just 
for the look of a game, and debate would rage over whether graphics were more 
important than gameplay. 

Despite the importance of such visuals, many games programmers in the 
early days tried to be a jack of all trades: writing code while also creating graphics 

and producing sound. So long as the graphics 
were representative, developers believed the job 
was done. This situation changed in the early 
1980s, however, when dedicated graphic artists 
joined small development teams and poured 
many hours into producing visually impressive 
games. Nintendo’s NES in particular saw 
graphics evolve spectacularly, while the 16-bit 
era brought with it intricate detail. 

Many techniques were also introduced 
over the years, including Mode 7 on the SNES, 
which allowed backgrounds to be scaled and 
rotated; parallax scrolling for backdrops; 
3D-rendered triangle-based geometry; and Full 
Motion Video. Pretty soon, realism became an 
objective, particularly in the PlayStation era of 
beginning it had been left to the imagination of 
players (and, in many cases, descriptions in the accompanying game manuals). 

One person who witnessed many of these changes is Dan Malone, a comic¬ 
book artist who inadvertently found himself working in the gaming industry, 
initially for Palace Software. He ended up working across a host of computers and 
consoles, from the 8-bit machines right through to the present-day platforms. In 
doing so, he was given access to increasingly complex hardware on which to flex his 
artistic talents and ended up working on some of the finest games ever made, from 
Speedball 2: Brutal Deluxe to The Chaos Engine. Dan has created the visual assets for all 
the games in this book. 


Graphic artists joined 
small development 
teams and poured 
many hours into 
producing visually 
impressive games 

the mid-1990s, whereas in the 
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You began your gaming career in 1985, but were you an artist prior to that? 

Yes, I’ve been drawing comics since I could pick up a pencil and Fve had a massive 
love for Marvel since I was a kid. Growing up in the 1960s and early 1970s, my dad 
would buy me many comics. When my parents split and my mum moved to Brussels, 
she’d send me a steady stream of American comics from an international bookshop 
that would sell anything from anywhere all over the world. I was truly inspired by the 
artistic talents of people such as John Severin and Jack Kirby and they really did have 
a massive influence on me. 

But how did you progress from comics to producing art for games? 

Well, that was an accident. Several months after I’d left art college, an old typography 
teacher sent me a cutting from an industry magazine called Campaign. It was an 
advertisement for a company called Palace 
Software which was looking for 2000AD- 
style artists and, because I was really into 
2000AD which I think is the best British 
comic ever made, I knew I needed to 
respond. I got an interview but even at that 
stage, I didn’t realise it had anything to 
do with games. It was a complete surprise 
to me. 

Did you have any experience at all with 
games before then? 

No, I wasn’t really a gamer. I knew that 
games were around and I’d heard of the 
Spectrum, Commodore, and the Amstrad CPC, but I hadn’t played a lot of computer 
games. My passion had been tabletop games of Dungeons & Dragons and I’d write 
my own D&D campaigns and illustrate them. It meant I had a knowledge of games 
and gaming in general, though. 

What was it like working for Palace Software? 

I was in London on my own for the first time as a young adult and it was especially 
great because we were working at the legendary independent Scala cinema in King’s 
Cross. We worked with Pat Mills from 2000AD, which was really exciting because it 
let me combine gaming with comics. It was a bright new world for me in London, 
having been in college in Ipswich. 

What was it like approaching art on 8-bit computers having had a 
background of using a pen? 

It was a real scale down. Apart from the limitations, the number of frames and 
the variety of backgrounds, I was working with pixels, which I always felt was like 
working with large Lego bricks. But Palace Software had in-house sprite editors and 
another artist - Steve Brown, who arrived just before me - had pretty much set 
everything up by the time I got there, which eased me in. Palace was also very artist- 
led: the company was about what the artist could deliver and how the machine could 
achieve it. 


I got an interview 
but even at that 
stage, I didn’t realise 
it had anything to 
do with games 
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Did you feel constrained by the technology? 

Well, it was my first job so my approach was to just get into it and do my best, but 
it was still a big shock and I would constantly look at comics and think, “Blimey, I 
really want to get back into that.” But I love animation and it was nice to use those 
skills, even though I was operating with a simple four-frame loop. I also seized the 
opportunity to create a little comic for Sacred Armour of Antiriad. 


How closely did you work with the coders? 

One of my jobs was to push the programmers at Palace and, after developing 
Cauldron //, I worked closely with a guy called Stanley Schembri on Sacred Armour 
of Antiriad. We sat side-by-side and I’d haggle for more graphics to do while they’d 
point out stuff that wasn’t working, which meant I’d have to cut the frames down or 
do something else. But it was great fun and there were some nice friendly battles. For 
instance, the main character in Sacred Armour of Antiriad was two four-by-four sprites 
joined together and that proved a bit of a push to get in. 


Was it frustrating to be told you couldn’t do certain things? 

You just have to readjust and realise that you’re working within a limitation and that 
it is your job to make it work. In that sense, any frustration turned into a challenge, 
more so when you consider I had no artistic reference point 
because I wasn’t really into any games. Coming to the job 
really fresh like that helped and it’s why I pushed what I was 
doing as much as I could. I spent about six months on Sacred 
Armour of Antiriad in total and it was pretty intense. 


A1986 interview 
with Dan in CRASH 
magazine, when 
he was working for 
Palace Software 


* 
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Creating new worlds 


Looking at the many artistic elements that make 

■ ENEMY EXPLOSION 

When an enemy is hit, it must react in 
some way. An explosion is a perfect visual 
because it’s not only bright, thereby 
reinforcing what has just taken place, it is 
also mightily satisfying. 

■ main playing area 

Dan Malone says he kept the background 
surface area of the game mostly blank 
so that the sprites could stand out more 
clearly,something which is always helpful 
to the player. 

■ player sprites 

Gamers are going to spend a lot of time 
looking at the main character sprites, so 
they need to be attractive and instantly 
distinguishable from other objects. Dan 
Malone gave the characters shadows to 
help make them feel grounded and solid 
against the background.They also had 


up The Chaos Engine 

different characteristics defined by skill, 
stamina, speed,and wisdom. 

■ STATUS AREA 

Whether you have a button to call up the 
current stats on a separate page or having it 
as part of the main playing screen, a status 
area is vital for displaying the current score, 
health, and pick-up in a game like this. 

■ MANY PUZZLES 

It’s always a good idea to challenge players, 
so as well as providing lots of enemies, 

The Chaos Engine let you pick up goodies 
such as keys,food,and treasure. Indicators 
would tell players when an exit was open 
or locked. 

■ maps 

Big games need maps, but The Chaos 
Engine kept things simple by showing a 
view of the three-screen square area around 
the character rather than the whole level. 


Node 
(level 
exit key) 
locked 


Level 

map 



Solid background 
areas - must stand 
out clearly from 
play area 


Level area 


Node (level exit 
key) unlocked 


Extra 


Shield 


Impact FX to show 
when an enemy 
sprite is hit 


Enemy sprites 
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Were you always looking to develop 
little tricks with your art? 

Not so much on the 8-bit computers 
because the pixels were massive and 
you really only had four colours and 
one transparent to play around with. 
But with the 16-bit stuff there was a 
little bit more you could push here and 
there, with little techniques such as anti¬ 
aliasing that ensured the graphics would 
look smooth and not overly pixellated. 


2 The Chaos Did you also work on the design of games? 

devisedTby The Yes, ^ WaS manc ^ ate to come U P with gaming concepts for 

Bitmap Brothers Sacred Armour of Antiriad and Superthief and develop ideas that 

would make them playable. To do this, I’d start by sketching 
the whole thing out on paper and there were periods where I’d 
just keep drawing until someone said, “Right, we’re starting development properly 
now.” At that point, I’d sort some graphics for the programmer to work with all the 
ideas bristling in my head. 


Why did you design on paper first rather than launch straight in? 

I can always think better when I’m drawing by hand. In fact, more often than not, 
I don’t have an idea in mind when I get down to drawing and so it helps them to 
emerge. The only exception is when I actually do have a strong idea and I’m itching 
to get it down, but I’m still very much old-school in my use of pen and paper, even 
though I know a lot of people draw on tablets and that I should maybe get into that. 


3 Sacred Armour 
of Antiriad 
on the ZX 
Spectrum 


Where did you get your ideas from? 

Well, I’d started to play a few games by this point so I was getting a feel for what would 
and wouldn’t work. Sacred Armour of Antiriad , for example, had prehistoric characters 
and alien technology and while it proved to be similar to another game called Turrican 
(even though I was designing it independently, miles away), it 
showed that I was on the right lines. 

I think it helped that I knew so much about games such 
as Dungeons & Dragons and understood what made a game a 
game. I also like sport and I saw games as a competition that 
worked within a set of rules. So that 
was my main influence, with comics 
always in the background. I’d read 
somewhere that writing a good book 
was as simple as getting readers to 
turn the page, so I felt that we should 
always encourage players to push 
on to the next level. I’d do this by 
including little teasers. 






201 


Artistically Speaking - Dan Malone 









4 Dan's comic- 
book-style 
artwork for 
an advert 
for Superthief 










There are lots of college courses 
everywhere catering for game design, 
3D modelling, and storyboarding 
making, so there is now a clearer route 
to employment. But it's a hard one. You 
need to be committed and sacrifice 
things along the way. 


Dan Malone 
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Did you find working on 16-bit computers rather Liberating? 

It certainly brought a lot of stuff to the table: greater resolution, more memory and 
more colours, for starters, and that was a big deal because you could anti-alias better. 
I remember that I was always looking at arcade machines with a view to bringing that 
vibe to the home computer. With 16-bit, it was suddenly possible to do that and it was 
such a breakthrough. I couldn’t wait to get involved. 

Was there a big difference in the types of graphics you were expected to 
produce for a 16-bit computer and a 16-bit console? 

At the time, we would always start by producing games on home computers, so we’d 
create them on the Amiga and Atari ST first and then port the graphics backwards 
and forwards on to other formats. On one occasion, when I was producing Speedball 2 , 
I created two separate palettes - one for the Atari ST and the other for the Amiga - 
but I held everybody up doing that. With the consoles, on the other hand, we were 
just porting games straight across before touching them up. We needed to get them 
to look good, which wasn’t always easy because the colours on the consoles were very 
garish and saturated. It was also harder to get 
nice, smooth anti-aliasing, but the good news is 
that we had a bit more memory on some of them 
when compared to the Amiga. 

You moved from Palace to join the Bitmap 
Brothers. Was it a special company to work 
for? 

It was a major highlight for me, definitely. At the 
time, Palace was on the verge of closing, but I’d 
already seen the Bitmaps’ Speedball and fallen in 
love with it. I thought the music, the graphics and 
the gameplay were just astounding and so I was 
really pleased to go straight in on Speedball 2 when I joined the Bitmap Brothers. It 
was very exciting, especially because the company had always been seen to be very 
cool. Not that Palace Software wasn’t like that - it was a great company to work for 
too - but it was just unfortunate that it ended because it could have been something 
really special. 

Were you given a lot of freedom at the Bitmap Brothers? 

Yes, and it’s a beautiful thing. I’ve always said that design by committee is not the best 
way of creating a standout product and I was very pleased by that. Speedball II, and 
The Chaos Engine , come to that, gave me a lot of freedom to do my thing. I think those 
games became my best work because of that. 

Of all of the games, which appealed most in terms of art? 

The Chaos Engine was a real favourite of mine. The Victorian feel and the steampunk 
vibe were good fun and I was given a lot of freedom with the characters, which meant 
the game became very close to my heart. I’d even go as far as saying the game was my 
baby, even though it was a Bitmap game and Eric Matthews was in charge of it. Just 
being allowed to get on with things is always good. 


I was always looking 
at arcade machines 
with a view to 
bringing that vibe to 
the home computer 
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When you approached The Chaos Engine and you were developing the 
steampunk style, what influenced you? 

There was a story in 2000AD which had a kind of Victorian steampunk vibe, but 
it was Steve Wilcox who pretty much conceptualised The Chaos Engine. I’d be sitting 
beside him drawing while he’d say, “Try this out, try that out.” Even so, it was very 

much a case of me following my 
nose because there wasn’t much to 
base the game around apart from 
a comic strip. I also had to adapt 
because I knew that I wouldn’t be 
able to get the sort of detailing 
you’d find in comics into a game 
at that time. But that’s why the 
characters in the game have always 
been a big favourite of mine and 
why I love those backgrounds. I’m 
particularly proud of the tile set for 
The Chaos Engine. 



2 Working on 
Speedball 2 
was a thrill 
for Dan 


As games became more 
advanced and development teams grew in size, did that 
affect how you approached your subsequent games? 

I started to became more of a creative director as time went 
on and that really entailed starting with a blank sheet of paper 
and inspiring the team, getting them to know what they were 
working on and why they were working on it. I was still drawing a lot - mainly the 
characters and the backgrounds - but I was mainly there to create a story with my 
games. It was like the Dungeons & Dragons thing again: we were creating rich worlds 
populated with characters and I had to get things ready for a deadline. It was all 
about making the artists and modellers share the same view. 


Creating a character 

Dan Malone works through six main stages when he creates art for his games. With this character, 
for instance, he’ll start by creating initial rough sketches that show the figure in various poses - for 
example, left, right, back,front, running, and standing still. Once he is satisfied, he’ll move on to the 
clean-up process, penning the lines that will be visible in the final character. With the image scanned 
into a computer, shadows and highlights are added and it’s time to lend some colour.The sprite can 
finally be scaled down for use in-game. 
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When did things really change? 

With the PlayStation. The development teams for the console were still tiny by 
today’s standards but very large for the day, with about 15 people in each. For me, 
it was a watershed moment and when I eventually joined Sony itself and got a blue 
PlayStation development kit, I was blown away. I’d play Wipeout and Tekken with my 
jaw dropping to the floor. I particularly remember the intro for Tekken blowing me 
away because it was so cinematic. 

Did it open your eyes to new approaches? 

In an environment like the one I was working in at Sony, it’s inevitable. I was 
alongside many other people and the job became a lot more about communicating 
ideas efficiently. But I was also checking other people’s work and delegating, which I 
had never done before. 

Was there a lot of pressure to 
showcase the PlayStation in the 
best light? 

It was still a case of giving each 
project the best you had, but it was 
a much bigger deal because more 
people were involved in the decision 
process and it would take a lot more 
time to get things passed. I worked 
on a licensed game called Porsche 
Challenge and that brought extra 
pressure because I also had to contend with Porsche having its own idea of how the 
game should look. That brought clashes because I wanted stuff like crazy paint jobs 
on the cars, but Porsche didn’t and that is basically why I left. It also pained me to see 
that another game I was working on - an original game — was canned in favour of 
a licence: NBA 97. I knew those games were bringing the money in, but in my mind 

this was Sony and I felt it should be leading 
the way. 

What was the game? 

It was a skate-surf hybrid — a precursor of 
sorts to Tony Hawk which came out a couple 
of years later and blew up the scene. I 
thought we’d missed a trick and I still think 
it was a shame we didn’t get to develop that. 

So did you feel constrained having 
to work with real models on Porsche 
Challenge? 

who worked closely with the Porsche specs 
d a story around it. But Porsche had a lot of 
)r me, it ultimately didn’t work. The game was 
3re playable and a nod to street-level culture. 




We had a good car modeller 
and it was more for me to buil 
influence over its licence and, f( 
OK, but it could have been m 


7 Harry Potter 
and the 
Chamber of 
Secrets on 
the GBA 


The development 
teams for the console 
were still tiny by 
today's standards but 
very large for the day 
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Porsche was conservative in 
what it wanted. 



You also created Harry Potter 
and the Chamber of Secrets 
for the Game Boy Advance. 

What was it was like working 
in 2D again? 

It was like going back to the 
16-bits really, although with 
a bigger palette and a similar 
resolution to the Amiga screen. 

But it was also a return to what I’d been doing several years 
before and it was also straightforward. Working with the Game 
Boy Advance was simply a case of reducing the graphics down 
to fit a small screen. The same rules of creating art applied. 


8 Dan worked on 
the character 
concepts for 
SSXBLur on 
Nintendo Wii 


Was there a different expectation of graphics in the 
2000s, though? 

Yes, a lot more realism came into it. We had greater polygon counts and texture maps 
and special effects, and there was more of a lean towards cinematic realism, certainly 
in the big games. In fact, it was all about big games, big teams, and big pressures. 


Was it refreshing to revise classics such as Broken Sword with its 
2D graphics? 

Yes, it was nice working with Charles Cecil and Dave Gibbons, who is a great British 
comic artist. I ended up working over his stuff and pretty much processing sprites and 
portraits from his artwork. 


So what should somebody seeking a career in games art do today to get 
their foot on the ladder? 

There are lots of college courses everywhere catering for game design, 3D modelling, 
and storyboarding making, so there is now a clearer route to employment. But it’s a 
hard one. You need to be committed and sacrifice things along the way. You also need 
to be aware that you don’t always get the fun stuff to start with - you may end up in a 

large team drawing rocks every 
day. But it’s a great job and 
working in the games industry 
is rewarding. Anyone with talent 
will do very well. 


9 Broken Sword: 
Shadow of the 
Templars on 
Nintendo Wii 
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SOUNDING OFF 


Talking music with 


Allister Brimble 


Music and sound effects can make a massive 
difference to the experience of playing a game. 
We chat to the musician who has created sound 
for games from the 1980s to the present day 
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V ideo games don’t work if you can’t display something on a 
screen. They can, however, be enjoyed without any sound. This 
imbalance makes for one of the most frustrating elements of a 
game musician’s job, as well as one of the most challenging. The 
overriding aim is to create audio that will have players wanting to 
crank up the volume rather than hit the mute button. 

At first, in gaming, audio played second fiddle to graphics and gameplay. 
Music would be used sparingly, perhaps for an intro or to introduce a level, and 
then basic effects would kick in although there were exceptions. Space Invaders , 
for instance, had a pulsating background sound accompanied by shooting noises 
whenever fire was pressed — but nothing you could call music. Melodies were few 
and far between. 

Part of the issue was the rudimentary technology to hand, combined with a 
lack of memory, forcing developers to compromise. It therefore took a few years for 
dedicated musicians to emerge but when they did, they were at least able to work 
with ever more advanced sound chips: the programmable sound generator chip for 
the Commodore 64, known as SID, has even been likened to a musical instrument. 

As time went on, audio just got better and better. Composers such as 
Rob Hubbard, David Whittaker, Martin Galway, and Ben Daglish became well 

known in gaming circles. Nintendo also saw 
the benefit of audio when it designed the NES 
with five channels, and there were experiments 
with sampled sound. The term ‘chiptunes’ was 
coined to describe synthesized electronic music 
created on 8-bit machines. Audio was given a 
further boost on the 16-bit platforms. 

The MOD computer file format came 
into being when Ultimate Soundtracker was 
released for the Commodore Amiga in 1987. 
Music could be based on digitised samples 
and it allowed songs to be created with vocals. 
The 16-bit consoles also had a greater number 
of sound channels and effects. When the CD 
format was introduced with 32-bit machines, 
quality jumped yet again, and some games 
would allow gamers to play their own compact discs. 

Audio remains crucial to games today and good musicians are highly prized 
among development teams. Games need music, sound effects, and spoken dialogue 
to work seamlessly and create an immersive environment for the player, in tandem 
with the on-screen action and narrative. 

British video game composer Allister Brimble has a career that tracks every 
generation of gaming. He began his career in the mid-1980s and continues to 
work, right through to the current day. Ever played Superfrog , Fantasy World Dizzy , 
Alien Breed , Sensible Golf Driver , Colin McRae Rally , Micro Machines V4, or even Goat 
Simulator ? Then you’ve heard some of his amazing output. 

Allister wrote the audio assets for all the games you program in this book. 


The term 'chiptunes' 
was coined to 
describe synthesized 
electronic music 
created on 
8-bit machines 
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You’ve been creating music for games 
for a long time. What was your musical 
background prior to entering the industry? 

I’d been interested in music from a young age 
and I was influenced by my parents who worked 
in the theatre. From the age of seven, I had piano 
lessons and although I wasn’t particularly good at 
them, I enjoyed playing, as I still do today I did 
O-level music at school, which in those days was 
very difficult on the theory side and I failed it. 
But the music in early computer games inspired 
me to want to create my own. 



AMIGA 

-- ■ FORMAT 


What initial steps did you take? 

I used to record games music on to tape and 
slow it down to hear how things were done. 

But in 1985, Melbourne House released Wham! 

The Music Box , and it allowed me to start 
experimenting with music. Even so, it wasn’t 
until the Commodore Amiga was released that 
I was really able to unlock my creativity with 
programs like Aegis Sonix and Sound Tracker. At that time, I had seen an article in a 
magazine in which a company called 17 Bit Software was asking for music that would 
be released for free into the public domain. I sent in some music and got a letter back 
saying they enjoyed it - 17 Bit later turned into a games company called Team 17 and 
I went on to produce music for some of its biggest titles. 


What was expected of a games musician in those early days? Did software 
houses treat music and sound as important parts of a game? 

With the early 8-bit and 16-bit games, you had to be able to work within limitations. 
For the 8-bit machines, music may have to fit in is as little as 2kB of memory and this 
meant typing patterns of notes one by one into a text editor and then sequencing 
these patterns to create a longer piece of music. You not only had to be a musician 
but to be aware of coding and the limitations of the hardware as well. The games 
were much simpler than today, so we generally just needed one piece of music and a 
few sound effects. However, with only one tune to rely on, we did have to make sure it 
was really good. Games composers came up with some inspired tunes in those days. 
Players appreciated the technical limitations and were often 
amazed at what was possible, so I think the music and sound 
was treated as an important part of the game, often even 
advertised on the game boxes. 

Which 8-bit machine allowed you to unleash your 
musical talent the most? 

The Spectrum 128K could play three tunes at the same time 
with full pitch and volume control and that was a massive 
jump from the ZX Spectrum 48K’s single-channel beeper. 


1 This Amiga Format 
issue's cover 
disk included 
'Brimble's Beats': 
some of Allister's 
game music 

2 The Commodore 
Amiga featured 
a four-channel 
sound chip 


212 











You worked at Codemasters 
in the early days, but how 
would you set about 
creating music for computer lmage credit; e Biu Bertram 2006 C c-by-2 . 5 

games there? 

My first titles for Codemasters were 

on the Commodore Amiga. The games usually had a very strong theme such as 
football or driving and I’d be shown early versions of the game where possible. 
I’d need to be aware of whether the music was for the title screen or in-game 
or both, so as to correctly match with the gameplay. The music for the Amiga 
was done on a music editor called Sound Tracker. I’d first go about creating an 
instrument set of short, sampled sounds that would fit into the required memory 
allowance of around 40kB. I’d then set about composing the music and creating 
the sound effects. 


One of the most prolific composers 
at the time, David Whittaker showed 
us all how it was done in games such 
as Glider Rider and he inspired 
me to want to create my own 
game music. Recently, Glider 
Rider’s music featured in 
my own remake album, 

The Spectrum Works 
(wfmag.cc/brimble). 


Were you producing music solely for home computers? 

Codemasters soon started producing games for the Nintendo NES. I was invited 
up to their offices in Leamington Spa and I was sat in front of a text editor and 

asked to compose some music. This was a far cry 
from the Amiga music I’d done before and I had 
to ask for help. I was shown how to create the 
various patterns and sequences as text and then 
test it out on a specially modified NES console. 
The specs for these games were much different, 
often requiring eight or ten tunes. 

You worked on some iconic games such 
as the Dizzy series. How would sound be 
used to enhance these titles and what 
limitations were you working under? 

Typically, the more graphically diverse games 
such as the Dizzy titles had a lot less memory left for audio. The music for Treasure 
Island Dizzy , for example, was done in something like 5kB of memory, which equates 
to five pages of text - compare that to 20 or 30 megabytes for audio today! I therefore 
had to create short, real-time synth instruments that took only 32 bytes of memory 
each for the Amiga. 


The music for 
Treasure Island 
Dizzy was done 
in something like 
5kB of memory 
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Did the switch to the Atari ST and Amiga take your approach to music to a 
different level? 

The Atari ST had much the same sound chip as the Spectrum 128 and its music 
sounded pretty much identical. However, the big jump forwards was the Amiga, 
which wasn’t limited to single bleeps but instead featured four-channel sampled 
sound, previously only available on very expensive synthesizers of the time, like the 
Fairlight CMI. Programs such as Sound Tracker 
allowed full sample manipulation, which inspired 
a whole new generation of musicians. 

Much of your work was on the Game Boy 
series of handhelds. Given that these 
machines were as likely to have been 
enjoyed without headphones as with, 
did you take into consideration that 
others would be more likely to overhear 
a handheld game being played and that, 
potentially, your audience could be a group 
of non-gamers sitting on public transport? 

Well, I have to apologise to everyone for those 
annoying tunes whilst sitting on public transport. 

I admit it’s my fault [laughs]. While it didn’t 
change my approach to making music, I did have to take into account that the 
sound was probably playing on the tiny built-in speakers. These had almost no bass 
response so some sounds - bass instruments or deep explosions - could just disappear 
unless you treated them correctly, almost having to turn them into a tinny radio 
sound to be heard at all. This did mean, though, that headphone users didn’t get the 
best experience. 

How did the consoles alter the approach to in-game music, though? 

The Amiga CD32 followed by the PlayStation were the really big changes with the 
advent of the CD player built in. This meant that music no longer had limitations 
and it became, well, just music played from a CD. 

Songs by pop and rock musicians began to be used in gaming soundtracks. 
What effect did that have on you? 

Having pop music works in some types of game. It’s good for racing games, for 
example, where you have a radio in your car and it makes sense to have popular 
tracks playing. But game music on the whole needs to be composed to fit a game 
and, these days, be adaptive; I don’t think many licensed tracks have achieved this. 
But recently I think we’ve been moving back to dedicated game composers who 
understand the likes of adaptive music. Of course, there will still be some popular 
rock and pop composers out there who still do a good job at this. 

Did their involvement alter the way music in games was perceived? 

For many, music lost its appeal in games for a bit. With no limitations, you could 
no longer be impressed by what was coming out of your speakers. But it was soon 


The Amiga wasn’t 
limited to single 
bleeps but 
instead featured 
four-channel 
sampled sound 
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Create classic tunes like a pro 

Allister Brimble gives us his top musical tips to help you create some hits 

TIP 1 Most 8-bit computers and consoles only had three channels for sound, meaning you could play 
three notes at the same time, so it’s important to remember to limit your compositions to only 
a few parts at any one time in order to give an 8-bit limited feel. 

TIP 2 Use fast arpeggios, also known as‘single-channel chords’-quickly alternating between several 
notes of a chord allows us to create the impression of chords on one channel, and it thus 
became the iconic sound of 8-bit. Some of the best examples are to be heard in Glider Rider by 
David Whittaker for the ZX Spectrum 128. 

TIP 3 Keep the sounds short, fast, and snappy. Short sounds work much better for 8-bit tunes 

because you can fit more into the same space.The exception to this might be a long,flowing 
lead instrument. 

TIP 4 Use plenty of effects. We would use echo effects on higher-pitched sound to give a sense of 
space. We’d also use pitch vibrato, especially on melody sounds, often delaying the vibrato 
for half a second before it kicked in.This made simple sounds much richer and smoother. On 
the whole we would avoid effects on the bass, which was better-sounding kept simple and 
therefore a more solid foundation to the track. 

TIP 5 A classic technique was to share a single channel for both bass and percussion, often placing 
a snare drum in-between the gaps in the bass-line. A little bit of white noise was also added 
to the start of the bass sound to create the impression of hi-hat percussion and had the side 
effect of giving extra attack to the bass. 



siiPigg 


Image credit: 
Evan Amos 
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Left to right: 
Glider Rider, a 
Commodore 64, 
and Allister's 
album, The 
Spectrum Works 


* You can hear examples of how Allister Brimble has recreated 8-bit tracks to modern-day standard on his album, 
The Spectrum Works, available at allisterhrimble.handcamp.com and on most current streaming platforms. 
He often overlays new parts which shadow the original 8-bit recordings for a much richer sound. 


215 


Sounding Off — Allister Brimble 
















I have always believed that music 
should not be bigger than the game. 
We need to listen to game music for a 
Long time and, let's face it, it's going to 
be turned off once it gets annoying! 


ALlister Brimble 



3 



3 ALLister first started 
experimenting with 
music using Wham! 
The Music Box by 
Melbourne House 
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realised that streamed CD audio did hold its own limitations, in that it was always 
linear, start-to-end, and could not adapt to gameplay. 

So when did adaptive music become integral to a gaming experience and 
what did it force musicians to consider? 

Adaptive music has been possible since the days of the Xbox and the PlayStation 2, 
but it has taken a while to take off and is still not fully utilised today in many cases. 
There are a few ways to do it, though, and the musician needs to consider how each 
game may benefit from each method. 

Most games simply have several parts to a track: a main looping part, a 
transition part that can hide the join to another part, and so on. Each part can be 
transitioned to depending on what’s happening during the game. This works for a 
lot of games. We can also break each part into 
layers - say, percussion, melody, and backing - 
and have different versions of each layer that 
can be switched between for varying levels of 
action. In a recent title I worked on, Scraps Nutty 
Adventure , there’s a skydiving game where you 
could fall at different speeds. I included music 
that would evolve based on a timeline 0 to 100. 

Various looping parts would fade in and out, and 
a bomb-dropping sound was introduced at the 
end. However fast you fell, the music would still 
seemingly play from start to end. 

What makes for good music and sound in 
games, then, and how has that evolved? 

Since my early days working for Team 17, I have always believed that music should 
not be bigger than the game. We need to listen to game music for a long time and, let’s 
face it, it’s going to be turned off once it gets annoying! Good in-game audio puts the 
sound effects and ambience first and the music in the background and it is written so 
as not to be annoying in the long run. In the old days, we’d have a big melody as that 
was our only chance to impress, but today we try and back off from melody and let 
the music do its job to enhance the gameplay. For sound effects, we try to introduce 
as much random variation as possible. For instance, a footstep sound might be made 
of 50 or more individual samples that vary each time of playing. 

For a spell in your career, you produced audio tracks which were distributed 
on the disks which came with some Amiga magazines. Can you tell me more 
about how they came about? 

Martyn Brown, the project manager at Team 17 software, had some connections with 
Amiga Format magazine and asked me to create a piece of music for one of their 
cover disks. The September 1990 issue included my track composed on the Game 
Music Creator software. It was a variation on Bach’s Prelude in C and Charles Gounod’s 
Ave Maria. I then made my own new version based on both, including guitar and rock 
beats! I’ve had people ask for it to be played at their funeral; I’m not sure if that’s 
good or not! 


Good in-game 
audio puts the 
sound effects and 
ambience first and 
the music in the 
background 
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Brimble’s Best 

1. ALIEN BREED 

(for Team 17 on the Commodore Amiga) 

This music was a hybrid of 8-bit synth and Amiga sampled sounds, 
something rarely heard on the Amiga. I created several tiny but 
complex 64 byte looping wave forms, including choral sounds and 
applied 8-bit techniques such as ADSR, vibrato,tremolo,and echoes. 
This created a unique Alien-esque atmosphere, and also meant that 
20 minutes of music fitted into 39kB of memory, which was some 
achievement at the time. 




2. SUPER FROG 

(for Team 17 on the Commodore Amiga) 

I was inspired by the C64 classics by Rob Hubbard and was asked to create 
some cute and funny themes for this game. The opening title was like the 
Superman theme but with a frog croak added after the intro fanfare for laughs. 
The Amiga had four sound channels, so the music had to be carefully composed 
so that channel four could be overwritten by sound effects and the listener not 
notice anything dropping out. 


3. ROLLERCOASTER TYCOON 
(for Chris Sawyer on the PC) 

Chris Sawyer’s famous game was a lot of fun to compose for. Each ride in 
the theme park had its own themed piece of music to go along with the 
sound effects.This meant that as you panned around the map, different 
tunes would fade in and out, based on proximity the various rides.The 
music therefore never became boring and the ambience created really 
helped to bring the game alive. 



4. ICE AGE: SCRAT’S NUTTY ADVENTURE 
(for Just Add Water & Outright Games on PS4,Xbox 
One, Nintendo Switch) 

This is my most recent title, and in this game I used 
techniques learnt over my whole career using some 
software called FMOD Studio,an audio interface 
that sits between the composer and the game.This 
allowed me to create adaptive music.The music for 
the skydiving part of the game evolves depending on 
how fast the player falls, and in the temple scene the 
music is randomly generated, sounding different each time. I also used additional layers for action so 
that when you fight enemies, the music becomes more intense. 
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5 The Amiga CD32- 
consoles with CD 
drives enabled 
music to played 
from the disc 

6 The Game Boy's 
tiny built- 

in speakers 
required careful 
treatment of 
sound and music 


Image credit: Evan Amos 


Of all of the games that you have made, which stand out musically for you 
and why? 

I’m probably most pleased with the music from Scraps Nutty Adventure , released in the 
autumn of 2019. It includes full interactive music and even some randomly generated 
music in the temple. 

Roller Coaster Tycoon for PC was another I was pleased with. Each ride had 
its own music that would fade in as you got close. It meant you were not listening to 
one piece of music all the time - it would be constantly changing. The sounds of the 
roller-coasters were also lovely once the game engine starting pitching them up and 
down with the loops and ramps. 



Image credit: 
Evan Amos 


Which of your games would suffer most if the sound was turned off? And 
how much of a challenge is it to ensure that gamers would 
want that sound up loud? 

I think all of them would suffer! But the games that suffer most are 
fighting games. With no punch and kick impacts, it feels like you 
are hitting with cotton wool, so I would have to say Body Blows by 
Team 17 on the Amiga, or Dragon: The Bruce Lee Story by Virgin 
Games on the SNES. 

To keep the sound up loud, sound effects have to be 
the main consideration and music has to be rich and varied 
and fully adapt to the gameplay. Repetition means the 
music will be sure to be turned off. 


Is the use of in-game audio heading in the right 
direction, would you say? 

Yes, just recently we have seen music in console 
games improve considerably. This is due to freely 
available middleware such as FMOD or Wwise, 
which composers can utilise to create adaptive 
music with an easy-to-use graphical user 
interface. I find that coming from an 8-bit or 
16-bit background is now a big advantage in 
utilising this software, as I learnt how to be 


220 







creative within limitations back then. Applying your own set of limitations is now the 
key to focus how you want things to sound. 

And how have you adapted to working with so many formats over the years? 

It started with a lot of limitations. Three notes at the same time, limited memory, and 
so on. Things slowly got better with the Amiga, and then the Super Nintendo where 
I could play eight sounds at once. It was a fairly easy transition up to there. We then 
got to the PlayStation and beyond. Now I needed a full music studio to create my 
music, but I was prepared as I’d already produced my first CD album in 1992, called 
Sounds Digital. In around 2000, I started to work more and more on handheld audio. 
This has now gone full circle back to the days of limitations, but it meant that I was 
one of the few remaining composers left with the old-school skills needed to fully 
utilise their audio capabilities. Today we are back to music produced in a studio but 
within the confines of adaptive music - a blend of old and new skills, and probably 
my favourite era so far. 

What is the biggest difference between then and now? 

It’s strange. Things have come full circle. I used to be able to create 8-bit music on 
one computer. That changed dramatically when I needed a full studio for PlayStation 
music. These days, though, I’m back to one computer with all my instruments and 
sounds contained in one place. 

If I had to pick one difference, it would be in the choices I now have at my 
fingertips. At any moment I can pull in any sound I need without having to worry 
about how I will make it. There are so many rich and varied instrument and sound 
libraries out there that you are almost spoilt for choice. 
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Code the Classics not only tells the stories of 
some of the seminal video games of the 1970s 
and 1980s, but shows you how to create your 
own games inspired by them using Python and 
Pygame Zero, following examples programmed 
by Raspberry Pi founder Eben Upton. 


Get game design 
tips and tricks from 
the masters 


Download and play 
game examples by 
Eben Upton 




Learn how to code 
your own games with 
Pygame Zero 


Explore the code 
listings and find out 
how they work 
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